The Year 2038 Bug - Y2K38 Problem - Many of your applications will crash

Try this First.

Sign out from yahoo messenger or gmail talk. Open your System Date and Time Settings. Change the year to anything beyond 2038. You can try setting the year to 2040. Now try logging in to either of the messenger. It does not log in and gives you some error. Surprised!

So, Where's the problem ?

The source of the problem is actually the way some(major) applications store their date/time data types. Programmes using POSIX time representation will be affected by this problem. The structure time_t is a value type which stores time in a 32-bit signed integer. It stores the time as number of seconds elapsed since January 1, 1970. So it is capable of representing time which can be addressed within total of 2³¹ seconds. According to this, the latest time that it can store is 03:14:07 UTC, Tuesday, January 19, 2038. After this time, the sign bit of the 32-bit signed integer will be set and it will represent a negative number. As I said, the time is stored as number of seconds elapsed since 1st January 1970, this negative number will be added to compute the time as per the POSIX standards. But this being a negative number it will calculate the time by subtracting this many seconds from 1st January 1970 which will eventually generate a historical date-time which will cause the applications to fail. This time will be Friday, December 1901 and is called the wrap-around date. Applications written in C in many operating system will also be affected as the POSIX presentation of time is widely used there. The animation below visualizes actual scenario in an easier manner. This bug is often denoted as "Y2038", "Y2K38", or "Y2.038K" bug.

Simulate the bug in a C Programme.

The following ANSI C programme when compiled simulates the bug. The output produced by the programme is also attached below the code. This code has been been referred from here.

#include <stdlib.h> 
#include <stdio.h> 
#include <unistd.h> 
#include <time.h> 
int main (int argc, char **argv) 
{ 
       time_t t; 
       t = (time_t) 1000000000;
       printf ("%d, %s", (int) t, asctime (gmtime (&t))); 
       t = (time_t) (0x7FFFFFFF); 
       printf ("%d, %s", (int) t, asctime (gmtime (&t))); 
       t++; 
       printf ("%d, %s", (int) t, asctime (gmtime (&t)));
 
return 0; 
} 

Output :

1000000000, Sun Sep 9 01:46:40 20012147483647, 
Tue Jan 19 03:14:07 2038-2147483648, 
Fri Dec 13 20:45:52 1901

Above programme being a strict ANSI, should compile using any C compiler on any platform. Now lets take a look at a perl script on both UNIX and Windows 2000. This script has been referred from here.

#!/usr/bin/perl # 
# I've seen a few versions of this algorithm 
# online, I don't know who to credit. I assume 
# this code to by GPL unless proven otherwise. 
# Comments provided by William Porquet, February 2004. 
# You may need to change the line above to # reflect the location of your Perl binary 
# (e.g. "#!/usr/local/bin/perl"). 
# Also change this file's name to '2038.pl'. 
# Don't forget to make this file +x with "chmod". 
# On Linux, you can run this from a command line like this: 
# ./2038.pl use POSIX; 
# Use POSIX (Portable Operating System Interface), 
# a set of standard operating system interfaces.

$ENV{'TZ'} = "GMT";

# Set the Time Zone to GMT (Greenwich Mean Time) for date 
# calculations.

for ($clock = 2147483641; $clock < 2147483651; $clock++) {
       print ctime($clock); }

# Count up in seconds of Epoch time just before and after the 
# critical event. 
# Print out the corresponding date in Gregorian calendar 
# for each result. 
# Are the date and time outputs correct after the critical 
# event second? 
        

A mere handful of operating systems appear to be unaffected by the year 2038 bug so far. For example, the output of this script on Debian GNU/Linux (kernel 2.4.22):

# ./2038.pl
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

Windows 2000 Professional with ActivePerl 5.8.3.809 fails in such a manner that it stops displaying the date after the critical second :

C:\>perl 2038.pl
Mon Jan 18 22:14:01 2038
Mon Jan 18 22:14:02 2038
Mon Jan 18 22:14:03 2038
Mon Jan 18 22:14:04 2038
Mon Jan 18 22:14:05 2038
Mon Jan 18 22:14:06 2038
Mon Jan 18 22:14:07 2038

Do we have a solution ?

Yes, Of course, There have been many solutions proposed worldwide for this problem. Few of them are listed here.

1.) Re-define the time_t structure as 64-bit.

This is not a solution as the binary compatibility of the software would break here. Programmes depending on the binary representations of time would be in trouble. So we can not even think of this one.

2.) Change time_t from 32-bit signed to 32-bit unsigned.

This seems to be good at first look, but this would just delay(post-pone) the judgement day to the year 2106 as it will give some more scope by adding another usable bit. You will be in the same trouble by then. So this is a feasible solution but not a practical one.

3.) Shift from 32-bit systems to 64-bit systems.

Most 64-bit architectures use 64 bit storage to represent time_t. The new wrap-around date with this new (signed)64 bit representation will not come before 290 billion years. It is positively predicted that by the year 2038 all 32-bit systems will be phased out and all systems will be 64-bit.

Thanks.

Ruchit S.
http://www.ruchitsurati.net/

You must Sign In to use this message board.

FAQ    Noise Tolerance Very HighHighMediumLowVery Low   Layout Expand Posts & RepliesThread ViewNo JavascriptNo JS + Preview   Per page 102550

Msgs 1 to 25 of 27 (Total in Forum: 27) (Refresh) FirstPrevNext

A foresight too-far-sighted Member 2340874 23:42 12 Jun '08   Hey, what do you think guys? Do we really have to scratch our heads for what would happen thirty years hence? I personally feel that stuff like this would be best handled by then generation. Or they may not even have to deal with this head-ache! With the pace things are headed, I can tell from deep conviction that the current generation OSs will have phased-out by then. What happened to the Y2K fuss? It came to a pass with the turn of the millenium and I really don't know whether it had cast its "evil spell" on any enterprise/ individual. BTW, Ruchit, I don't mean to poke fun at your article. Indeed, this was a good one. Nevermind. Sign In·View Thread·PermaLink Re: A foresight too-far-sighted robzzzzz 2:54 16 Jun '08   What really do you think happened behind the media "Y2K fuss"? Me and tons of other programmers went through project after project and those few (of the projects I was responsible) that used date and time, was put through practical tests and analysis. Where problems were identified, amendments were made or the program/system was replaced with something else. There is a good reason "nothing happened". /rob Sign In·View Thread·PermaLink It will pay our rent PC-Alex 19:22 27 May '08   If any 32-Bit-application will still be running in 2038, they will fetch us out of the old-peoples-clinics and we'll be engaged for migration strategies, because nobody will be able to deal with ancient 32-Bit code. But then: I do not believe that any application from today will still run then, OK, perhaps in a museum. Didn't they say that the sun also loses its light around that time Sign In·View Thread·PermaLink plagiarized article, no attribution given, unauthorized re-licencing William Porquet 10:35 7 May '08   I am the author of some of the material that is presented here as someone else's work. http://www.2038.org/ http://maul.deepsky.com/%7Emerovech/2038.html He even linked to my site for the source code, but mysteriously decided not to credit it?! Tsk, tsk, would it have hurt so much to give me a link? Sincerely, William Porquet http://www.2038.org/ william@2038.org Sign In·View Thread·PermaLink 4.43/5 (5 votes) Re: plagiarized article, no attribution given, unauthorized re-licencing Ruchit Surati 10:53 7 May '08   Hi William, I've used wikipedia for the gif reference and another site as well for code referencing. I've given the link in the article to the reference. Please provide me with the reference of the web-page from where you think the content has been taken from. I'M OF THE GENUINE OPINION TO GIVE AWAY PROPER CREDITS WHICH I'VE DONE BY LINKING AND MENTIONING IN THE ARTICLE. Still, in this case I'd revise the article with your reference and ADD propoer credits. sorry for the inconvinince. Thanks, Ruchit S. Ruchit S. ****************************************** Sign In·View Thread·PermaLink Re: plagiarized article, no attribution given, unauthorized re-licencing Ruchit Surati 11:02 7 May '08   one more thing, I had already done lot of research before writing this article. I needed some good tested program to simulate the problem, and there I found the pearl one , on your site. I guess linking makes it a difference , by giving a due credit to the original author. We are doing quite a diff. work around here around the problem. I really had no intention to re-publish the cotnent of someone that's why it's been properly mentioned in the text with a ref. Thanks. Ruchit S. http://ruchitsurati.net ****************************************** Sign In·View Thread·PermaLink Re: plagiarized article, no attribution given, unauthorized re-licencing William Porquet 11:20 7 May '08   Hello Ruchit, I appreciate your prompt attention to this matter. First of all, the language is "Perl", the semi-precious gem is a "pearl". You quoted me verbatim with regard to the outputs, without so much as a set of quotation mark and a link. I suggest you correct this ASAP. Sincerely, William Sign In·View Thread·PermaLink 4.43/5 (5 votes) My solution [modified] john wallis 0:55 7 May '08   We could use the Earth precession, but that would only be good for 26000 years or so. Sol (our Sun) travels around the Milky Way in 240*10^6 years; a satellite tracking the Earth, the Sun, the center of the Milky Way and another very far object could be translated into a time. On the other hand the Sun will become instable in 3*10^9 years - maybe we could monitor its evolution tract ... Then of course, there's decay... Maybe a "decay chip" could be used - only problem there is high speeds or high masses . We could seed a planet with life. It should be good for at least 4.5*10^9 years of monitoring. modified on Wednesday, May 7, 2008 6:06 AM Sign In·View Thread·PermaLink 5.00/5 (1 vote) Re: My solution Douglas R. Keesler 18:40 7 May '08   Cool... or in 30 years we [that is MS] could just change the arbitrary date reference point from Jan 1, 1970 to say Jan 1, 2000. I know, it's not as exciting -- but it would be a lot cheaper and easier. In business, if two people always agree, one of them is unnecessary. modified on Thursday, May 8, 2008 12:32 AM Sign In·View Thread·PermaLink Do we have a solution ? T-Mac-Oz 22:28 6 May '08   The "Y2038 Bug" was well & truly acknowledged even while the press was beating up Y2K. There are 2 reasons why it doesn't get much press coverage now: 1) "All Consumer Electronics will Fail in 30 Years" is not much of a headline. 2) Y2K ended up being a complete fizzer, none of the expected catastrophes happened. That being said, there's a couple of other points to note in your article: Solution 2 has many more short-comings than merely postponing the inevitable: for one thing, it's got to applied in context, e.g. Birth dates: there are an awful lot of people still kicking around that were born before 1970. Doesn't solution 3 (shift from 32 - 64 bit architecture) suffer the same problems as solution 1 (redefine the time_t structure as 64 bit)? After all, it's serialisation/storage that is the real issue. Simply redefining time_t (which is actually a typedef not a struct) would introduce fewer complications than porting the entire code base from 32 to 64 bit (pointer and array index sizes, sizeof(xxx) changes ...). Any coder that performs serialisation in this day & age without including some form of version identification (which would indicate whether 32-64 bit time_t conversion needs to be performed) should be summarily shot anyway . Even embedded systems' firmware upgrades should/could check the previous firmware version & perform the necessary conversion(s). Fortunately, most RDBMS's have been using 64-bit date/time as standard for many years (e.g. ODBC's DATE type - typedef'd from a double or 64 bit floating point number on 32 bit systems) so the Y2038 is likely to turn out more of a fizzer than even Y2K. T-Mac-Oz Sign In·View Thread·PermaLink 5.00/5 (1 vote) Very good Hans Dietrich 17:55 6 May '08   This is valuable information to keep in mind. It would be interesting if you could add some further notes about what steps software vendors are taking, or what the IT press is reporting. Best wishes, Hans [CodeProject Forum Guidelines] [How To Ask A Question] [My Articles] Sign In·View Thread·PermaLink 4.00/5 (1 vote) better buggy whips.... Douglas R. Keesler 17:53 6 May '08   Considering the first PC was introduced less than 30 years ago sporting a single floppy drive and 64K RAM, and considering how far technology has come in that time... addressing a date problem 30 years future seems a bit like a company in the 1920's beginning work on a prototype buggy whip to be introduced in the 1950's ... or scientists addressing a problem the world will face 30 million years from now. In the world of technology 30 years is an eternity. I guess the topic has some academic interest, and the article is fairly well written -- but it has no practical value (IMO). In business, if two people always agree, one of them is unnecessary. Sign In·View Thread·PermaLink 5.00/5 (2 votes) Re: better buggy whips.... Rajesh R Subramanian 19:34 6 May '08   Douglas R. Keesler wrote: In the world of technology 30 years is an eternity. I guess the topic has some academic interest, and the article is fairly well written -- but it has no practical value (IMO). I agree completely. I think, if the ANSI C program (discussed in the article) is, for some reason, being used in the year 2038, we will need to worry more about that. Nobody can give you wiser advice than yourself. - Cicero .·´¯`·->Rajesh<-·´¯`·. Codeproject.com: Visual C++ MVP Sign In·View Thread·PermaLink 5.00/5 (1 vote) Re: better buggy whips.... Lee Humphries 21:24 6 May '08   Disagree (but just a little) - there's a lot of C code out there, and I'll be betting that some will still be running in 30 years time. You'll find it in the IS shops where you get the sort of "we can't replace it because we don't have the source code" comment from the "If it ain't broke don't fix it" type of IS managers - i.e. those that don't want to learn anything new because "all the best stuff has already been invented" and "a GUI is for wimps". I am convinced that lobotomising users will make little to no difference. Sign In·View Thread·PermaLink Re: better buggy whips.... Ruchit Surati 21:35 6 May '08   Hi Douglas, I completely agree with you. This is more of an acedemic value and I'm a firm believer that we'll never come across this practical situation. By the year 2038, all system would be migrated to 64bit architecture or above, which by default solves the problem. The motive behind writing this article, is just to explore thought over a possibility. What do you say ? Thanks. Ruchit S. http://ruchitsurati.net ****************************************** Sign In·View Thread·PermaLink Re: better buggy whips.... N-O-R-B-E-R-T 21:53 6 May '08   Of course, there are 30 more years if you just want to display the current date. Some sort of simulation software, or other magical voodoo prediction tools might encounter such problems years before that date. At least if they use time_t for such future dates. It's good to have read about that, since I wouldn't even have thought of checking how far time_t goes. Sign In·View Thread·PermaLink Re: better buggy whips.... Wong Shao Voon 22:15 6 May '08   Once I read from CodeProject daily news. IIRC, some insurance banks already encounter this problem for new insurances to be paid for 30 years. Or is it 30 years house loans? Couldn't remember. Sign In·View Thread·PermaLink Re: better buggy whips.... Douglas R. Keesler 17:54 7 May '08   That's nonsense. First, this issue is not a "bug" -- it is simply a limitation of the "system" time function. Thus any code functions deriving from system time (such as CTime, time_t, etc) will bear this limitation... but I'm sure you are aware that COLEDateTime handles dates/time from Jan 1, 100 - December 31, 9999. This issue is strictly with the system clock and has nothing to do with the ability of software developers to write date dependent software such as mortgage/loan amortizations etc... or to do far future date calculations. In business, if two people always agree, one of them is unnecessary. Sign In·View Thread·PermaLink Re: better buggy whips.... robertjb20 4:43 7 May '08   It was this kind of attitude that caused the rush to fix the y2k problem at the last miunnute back in 1999. Look how long it took before action was taken to correct the September 9,1999 date problem (9999), the Y2K problems? There were warnings of these problems years before it became a big priority to fix them. There are still many companies that have not converted to the 4 digit representation for the year which causes another problem until the year 2032 (08/06/25) - 2008 ? 2025? I wouldn't count on the y38k problem to be solved anytime soon based on the previous history of simular problems unless these warnings are taken seriously now and fixed now. Sign In·View Thread·PermaLink 5.00/5 (1 vote) Re: better buggy whips.... Douglas R. Keesler 18:17 7 May '08   robertjb20 wrote: It was this kind of attitude that caused the rush to fix the y2k problem at the last miunnute back in 1999. Right... and the Y2K problem was devastating, eh? robertjb20 wrote: There are still many companies that have not converted to the 4 digit representation for the year So what? It doesn't matter how the date is displayed, it only matters whether the software knows what the date is internally and can compute it properly. robertjb20 wrote: I wouldn't count on the y38k problem to be solved anytime soon And it doesn't need to be solved anytime soon.. And like Y2K, it's not a "bug" -- it's simply a limitation of System Time. Right now, system time stores times as seconds elapsed since Jan 1, 1970. Fine! In 2030 if we are still running 32bit systems, then make time a value of seconds elapsed since Jan 1, 1990. That's was a toughie, eh? Because System Time bears this limitation doesn't mean software developers can't write code that handles future dates. If you are a C++ developer look at COLEDATETIME in your MSDN -- it already handles dates/times from Jan 100 to December 9999. If that's not good enough you could always write your own date/time management class. Look banks and major corporations aren't buying $19 shareware apps to manage their data. They use software developed by "real" programmers, who don't tie their code to the limitations of the system clock. What a novel idea! In business, if two people always agree, one of them is unnecessary. Sign In·View Thread·PermaLink Re: better buggy whips.... BC3Tech 12:20 7 May '08   Agreed. With the availability of 64-bit systems to even home users right now, it seems that this won't be an issue in 30 years. Especially in critical applications. Sign In·View Thread·PermaLink 5.00/5 (2 votes) Re: better buggy whips.... Stefan Melaet 2:24 13 May '08   I fully agree, are we still using 32-bit processors in 2038? And when we're in 2038 are we still using software from today? Sign In·View Thread·PermaLink 4.00/5 (1 vote) The year 2106 Tak 13:43 6 May '08   This seems to be good at first look, but this would just delay(post-pone) the judgement day to the year 2106 as it will give some more scope by adding another usable bit. You will be in the same trouble by then. I pretty much doubt that I will be in trouble in 2106 (or any other of the current CP users)... that would make me 126 years old Sign In·View Thread·PermaLink 5.00/5 (1 vote) Re: The year 2106 08989088 17:04 6 May '08   2106,almost 100 years.I think we will found a perfect solution before that . maybe people at that age would use another operation system.And a very clearly thing we will see,our software maybe down long before that. Sign In·View Thread·PermaLink Re: The year 2106 Luis Alonso Ramos 17:29 6 May '08   2106? By then legacy systems will be 256-bit, and 32/64-bit will only appear on whatever becomes of Wikipedia Luis Alonso Ramos Intelectix Chihuahua, Mexico My Blog! Sign In·View Thread·PermaLink 5.00/5 (1 vote)

Last Visit: 21:51 9 Feb '10     Last Update: 21:51 9 Feb '10 12 Next »