[ILUG] [OT] Important Issue with "TIME" as we had with Y2K.

[Animesh]

This has been issue on MS $ long back. Has been already taken care in Linux.

Animesh.
----- Original Message ----- 
From: "bimal pandit" <bimal_pandit at rediffmail.com>
To: <ilug at linux.ie>; <phpug at lists.iephpug.org>; 
<squid-users at squid-cache.org>; <netfilter at lists.netfilter.org>; 
<Ext3-users at redhat.com>; <listmanager at lists.sendmail.org>; 
<dulug at dulug.duke.edu>
Sent: Saturday, May 20, 2006 12:01 AM
Subject: [ILUG] [OT] Important Issue with "TIME" as we had with Y2K.


Dear User,

In my previous article published in darpan 28/04/06 I mentioned  " 
technology is changing rapidly and there could be some unanticipated 
issues", so here is the time to look into one...

"Date" is one of the well known representation of "Time" and plays a 
critical role in our life. Just for an example our financial transactions, 
Important events, various schedules etc. all are directly related to 
"date/time", similarly it plays an important role in IT industry, our system 
uses date for various purposes e.g. various updates, application/program 
execution, backup schedules etc. etc. etc. and hence any variation, 
misrepresentation, error may lead to a great consequences. I hope you all 
remember Year 2000(Y2K) problem, just for ready reminder - in fact it was 
the way we represent "date" i.e. 05/05/75 is 5th May 1975, so date could be 
of maximum two digits(01-31), month could be of maximum two digits(01-12) 
but year needs to be four digits till "9999" and hence system could have 
gone haywire after the midnight of 31st December 1999 when the date was 
01/01/00. This was what??? start of the first century or the twenty first 
century(1st January 2000)???, this misrepresentation and use had a great 
implications!!! but things were controlled soon with the change in this 
format, you all know that.

But, why I am discussing all these???  OK, let me tell you another such an 
issue its "Year 2038 Problem", just go through this article which I have 
received long ago in a LINUX user group from Mr.Nitin Gupta, CEO, Xaprio 
Solutions.
------------ SNIP ---------------
The Year 2038 Problem, Test it now...
Disclaimer : This is just for FYI only. This  is true and if you do this do 
at your own risk!!!
 1. login to yahoo messenger(YM)/Gaim
 2. send instant message to anyone - fine its working...
 3. now, change your system date to 19-Jan-2038, 03:14:07 AM or above
 4. Confirm weather your date is changed
 5. again send instant message to anyone...
 Your YM/GAIM crashes ...
 * * YES ALL NETWORK BASED APPLICATION WILL NOT WORK NOW AND YOU MAY FACE 
ISSUES WITH OTHERS * *

Why...,  What is it?
 Starting at GMT 03:14:07, Tuesday, January 19, 2038, It is expected to see 
lots of systems around the world breaking magnificently: satellites falling 
out of orbit, massive power outages (like the 2003 North American blackout), 
hospital life support system failures, phone system interruptions, banking 
errors, etc. One second after this critical second, many of these systems 
will have wildly inaccurate date settings, producing all kinds of 
unpredictable consequences. In short, many of the dire predictions for the 
year 2000 are much more likely to actually occur in the year 2038!

Consider the year 2000 just a dry run. In case you think we can sit on this 
issue for another 30 years before addressing it, consider that reports of 
temporal echoes of the 2038 problem are already starting to appear in future 
date calculations for mortgages and vital statistics! In the first month of 
the year 2038 C.E. many computers will encounter a date-related bug in their 
operating systems and/or in the applications they run. This can result in 
incorrect and wildly  inaccurate dates being reported by the operating 
system and/or applications. The effect of this bug is hard to predict, 
because many applications are not prepared for the resulting "skip" in 
reported time anywhere from 1901 to a "broken record" repeat of the reported 
time at the second the bug occurs. Also, may make some small adjustment to 
the actual time the bug expresses itself. This bug to cause serious problems 
on many platforms, especially Unix and Unix-like platforms, because these 
systems will "run out of time".

What causes it?
Time_t is a data type used by C and C++ programs to represent dates and 
times internally. (Windows programmers out there might also recognize it as 
the basis for the CTime and CTimeSpan classes in MFC.) time_t is actually 
just an integer, a whole number, that counts the number of seconds since 
January 1, 1970 at 12:00 AM Greenwich Mean Time. A time_t value of 0 would 
be 12:00:00 AM (exactly midnight) 1-Jan-1970, a time_t value of 1 would be 
12:00:01 AM (one second after midnight) 1-Jan-1970, etc..

some example times and their exact time_t representations:
Date & time time_t representation
1-Jan-1970, 12:00:00 AM GMT 0
1-Jan-1970, 12:01:00 AM GMT 60
1-Jan-1970, 01:00:00 AM GMT 3 600
2-Jan-1970, 12:00:00 AM GMT 86 400
1-Jan-1971, 12:00:00 AM GMT 31 536 000
1-Jan-1972, 12:00:00 AM GMT 63 072 000
1-Jan-2038, 12:00:00 AM GMT 2 145 916 800

By the year 2038, the time_t representation for the current time will be 
over 2 140 000 000. And that's the problem. A modern 32-bit computer stores 
a "signed integer" data type, such as time_t, in 32 bits. The first of these 
bits is used for the positive/negative sign of the integer, while the 
remaining 31 bits are used to store the number itself.

The highest number these 31 data bits can store works out to exactly 2 147 
483 647. A time_t value of this exact number, 2 147 483 647, represents 
January 19, 2038, at 7 seconds past 3:14 AM Greenwich Mean Time. So, at 
3:14:07 AM GMT on that fateful day, every time_t used in a 32-bit C  or C++ 
program will reach its upper limit. One second later, on 19-January-2038 at 
3:14:08 AM GMT, disaster strikes. When a signed integer reaches its maximum 
value and then gets incremented, it wraps around to its lowest possible 
negative value. This means a 32-bit signed integer, such as a time_t, set to 
its  maximum value of 2 147 483 647 and then incremented by 1, will 
become -2 147 483 648. Note that "-" sign at the beginning of this large 
number. A time_t value of -2 147 483 648 would represent December 13, 1901 
at 8:45:52 PM GMT. So, if all goes normally, 19-January-2038 will suddenly 
become 13-December-1901 in every time_t across the globe, and every date 
calculation based on this figure will go haywire. And it gets worse. Most of 
the support functions that use the time_t data type cannot handle negative 
time_t values at all. They simply fail and return an error code.

Solution
"The best way to predict the future is to engineer it." Consider testing 
your mission-critical code well ahead of time on a non-production test 
platform set just before the critical date. For more general applications, 
just using large types for storing dates will do the trick in most cases. 
For example, in GNU C, 64-bits (a "long " type) is sufficient to keep the 
time from rolling over for literally geological eons This just means any 
executables the operating systems runs will always get the correct time 
reported to them when queried in the correct manner.  It doesn't stop the 
executables you may still want to be worried about Well-written programs can 
simply be recompiled with a new version of the library that uses, for 
example, 8-byte values for the storage format. This is possible because the 
library encapsulates the whole time activity with its own time types and 
functions (unlike most mainframe programs, which did not standardize their 
date formats or calculations). So the Year 2038 problem should not be nearly 
as hard to fix as the Y2K problem was.

Admittedly, some don't feel that this impending disaster will strike too 
many people. They reason that, by the time 2038 rolls around, most programs 
will be running on 64-bit or even 128-bit computers. In a 64-bit program, a 
time_t could represent any date and time in the future out to 292 000 000 
000 A.D., which is about 20 times the currently estimated age of the 
universe. The problem with this kind of optimism is the same root problem 
behind most of the Year 2000 concerns that plagued the software industry in 
previous years: Legacy Code. Even if every PC in the year 2038 has a 64-bit 
CPU, there will be a lot of older 32-bit programs running on them.  The 
greatest danger with the Year 2038 Problem is its invisibility. The 
more-famous Year 2000 is a big, round number; it only takes a few seconds of 
thought, even for a computer-illiterate person, to imagine what might happen 
when 1999 turns into 2000. But January 19, 2038 is not nearly as  obvious. 
Software companies will probably not think of trying out a Year 2038 
scenario before doomsday strikes. Of course, there will be some warning 
ahead of time. Scheduling software,billing programs, personal reminder 
calendars, and other such pieces of code that set dates in the near future 
will fail as soon as one of their target dates exceeds 19-Jan-2038, assuming 
a time_t is used to store them.
------------ SNIP ---------------
OK, so by that time I don't know where we will be and what would be the 
technology, but the message is clear. In the last let Me ask you a very 
interesting question...

could you tell me what was the day of the week on 3rd Sept. 1752 ? No!!!, 
OK, then have a choice and tell me for any of these 5th Sept. 1752, 9th 
Sept. 1752, 12th Sept. 1752.

regards,

Bimal Pandit-- 
Irish Linux Users' Group mailing list
About this list : http://mail.linux.ie/mailman/listinfo/ilug
Who we are : http://www.linux.ie/
Where we are : http://www.linux.ie/map/