Click here to Skip to main content
11,431,373 members (67,974 online)
Click here to Skip to main content

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

, 6 May 2008 CPOL
Rate this:
Please Sign up or sign in to vote.
The Year 2038 Bug - Y2K38 Problem.

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 231 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 <span class="code-keyword"><stdlib.h> </span>
#include <span class="code-keyword"><stdio.h> </span>
#include <span class="code-keyword"><unistd.h> </span>
#include <span class="code-keyword"><time.h> </span>
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/

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Ruchit S.
Software Developer (Senior) InteractCRM
India India
No Biography provided

Comments and Discussions

 
GeneralMy vote of 4 Pin
Slacker00710-Dec-10 1:15
memberSlacker00710-Dec-10 1:15 
GeneralA foresight too-far-sighted Pin
Member 234087412-Jun-08 23:42
memberMember 234087412-Jun-08 23:42 
GeneralRe: A foresight too-far-sighted Pin
robzzzzz16-Jun-08 2:54
memberrobzzzzz16-Jun-08 2:54 
GeneralIt will pay our rent Pin
PC-Alex27-May-08 19:22
memberPC-Alex27-May-08 19:22 
Generalplagiarized article, no attribution given, unauthorized re-licencing Pin
William Porquet7-May-08 10:35
memberWilliam Porquet7-May-08 10:35 
GeneralRe: plagiarized article, no attribution given, unauthorized re-licencing Pin
Ruchit Surati7-May-08 10:53
memberRuchit Surati7-May-08 10:53 
GeneralRe: plagiarized article, no attribution given, unauthorized re-licencing Pin
Ruchit Surati7-May-08 11:02
memberRuchit Surati7-May-08 11:02 
GeneralRe: plagiarized article, no attribution given, unauthorized re-licencing Pin
William Porquet7-May-08 11:20
memberWilliam Porquet7-May-08 11:20 
AnswerMy solution [modified] Pin
john wallis7-May-08 0:55
memberjohn wallis7-May-08 0:55 
GeneralRe: My solution Pin
Douglas R. Keesler7-May-08 18:40
memberDouglas R. Keesler7-May-08 18:40 
QuestionDo we have a solution ? Pin
T-Mac-Oz6-May-08 22:28
memberT-Mac-Oz6-May-08 22:28 
GeneralVery good Pin
Hans Dietrich6-May-08 17:55
mvpHans Dietrich6-May-08 17:55 
Generalbetter buggy whips.... Pin
Douglas R. Keesler6-May-08 17:53
memberDouglas R. Keesler6-May-08 17:53 
GeneralRe: better buggy whips.... Pin
Rajesh R Subramanian6-May-08 19:34
mvpRajesh R Subramanian6-May-08 19:34 
GeneralRe: better buggy whips.... Pin
Lee Humphries6-May-08 21:24
memberLee Humphries6-May-08 21:24 
GeneralRe: better buggy whips.... Pin
Ruchit Surati6-May-08 21:35
memberRuchit Surati6-May-08 21:35 
GeneralRe: better buggy whips.... Pin
N-O-R-B-E-R-T6-May-08 21:53
memberN-O-R-B-E-R-T6-May-08 21:53 
GeneralRe: better buggy whips.... Pin
Wong Shao Voon6-May-08 22:15
memberWong Shao Voon6-May-08 22:15 
GeneralRe: better buggy whips.... Pin
Douglas R. Keesler7-May-08 17:54
memberDouglas R. Keesler7-May-08 17:54 
GeneralRe: better buggy whips.... Pin
robertjb207-May-08 4:43
memberrobertjb207-May-08 4:43 
GeneralRe: better buggy whips.... Pin
Douglas R. Keesler7-May-08 18:17
memberDouglas R. Keesler7-May-08 18:17 
GeneralRe: better buggy whips.... Pin
BC3Tech7-May-08 12:20
memberBC3Tech7-May-08 12:20 
GeneralRe: better buggy whips.... Pin
Stefan Melaet13-May-08 2:24
memberStefan Melaet13-May-08 2:24 
GeneralThe year 2106 Pin
Tak6-May-08 13:43
memberTak6-May-08 13:43 
GeneralRe: The year 2106 Pin
089890886-May-08 17:04
member089890886-May-08 17:04 
GeneralRe: The year 2106 Pin
Luis Alonso Ramos6-May-08 17:29
memberLuis Alonso Ramos6-May-08 17:29 
2106? By then legacy systems will be 256-bit, and 32/64-bit will only appear on whatever becomes of Wikipedia Smile | :)

Luis Alonso Ramos
Intelectix
Chihuahua, Mexico

My Blog!

GeneralRe: The year 2106 Pin
supercat97-May-08 16:06
membersupercat97-May-08 16:06 
GeneralRe: The year 2106 Pin
Jeremy Falcon9-May-08 10:34
memberJeremy Falcon9-May-08 10:34 
GeneralRe: The year 2106 Pin
jwalker34315-Apr-10 18:23
memberjwalker34315-Apr-10 18:23 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.150428.2 | Last Updated 6 May 2008
Article Copyright 2008 by Ruchit S.
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid