Click here to Skip to main content
11,412,445 members (65,174 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))); 
       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 ''. 
# Don't forget to make this file +x with "chmod". 
# On Linux, you can run this from a command line like this: 
# ./ 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):

# ./
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 fails in such a manner that it stops displaying the date after the critical second :

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.


Ruchit S.


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


About the Author

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

Comments and Discussions

GeneralMy vote of 4 Pin
Slacker007 at 10-Dec-10 1:15
memberSlacker00710-Dec-10 1:15 
GeneralA foresight too-far-sighted Pin
Member 2340874 at 12-Jun-08 23:42
memberMember 234087412-Jun-08 23:42 
GeneralRe: A foresight too-far-sighted Pin
robzzzzz at 16-Jun-08 2:54
memberrobzzzzz16-Jun-08 2:54 
GeneralIt will pay our rent Pin
PC-Alex at 27-May-08 19:22
memberPC-Alex27-May-08 19:22 
Generalplagiarized article, no attribution given, unauthorized re-licencing Pin
William Porquet at 7-May-08 10:35
memberWilliam Porquet7-May-08 10:35 
GeneralRe: plagiarized article, no attribution given, unauthorized re-licencing Pin
Ruchit Surati at 7-May-08 10:53
memberRuchit Surati7-May-08 10:53 
GeneralRe: plagiarized article, no attribution given, unauthorized re-licencing Pin
Ruchit Surati at 7-May-08 11:02
memberRuchit Surati7-May-08 11:02 
GeneralRe: plagiarized article, no attribution given, unauthorized re-licencing Pin
William Porquet at 7-May-08 11:20
memberWilliam Porquet7-May-08 11:20 
AnswerMy solution [modified] Pin
john wallis at 7-May-08 0:55
memberjohn wallis7-May-08 0:55 
GeneralRe: My solution Pin
Douglas R. Keesler at 7-May-08 18:40
memberDouglas R. Keesler7-May-08 18:40 
QuestionDo we have a solution ? Pin
T-Mac-Oz at 6-May-08 22:28
memberT-Mac-Oz6-May-08 22:28 
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 Big Grin | :-D .
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.


GeneralVery good Pin
Hans Dietrich at 6-May-08 17:55
mvpHans Dietrich6-May-08 17:55 
Generalbetter buggy whips.... Pin
Douglas R. Keesler at 6-May-08 17:53
memberDouglas R. Keesler6-May-08 17:53 
GeneralRe: better buggy whips.... Pin
Rajesh R Subramanian at 6-May-08 19:34
mvpRajesh R Subramanian6-May-08 19:34 
GeneralRe: better buggy whips.... Pin
Lee Humphries at 6-May-08 21:24
memberLee Humphries6-May-08 21:24 
GeneralRe: better buggy whips.... Pin
Ruchit Surati at 6-May-08 21:35
memberRuchit Surati6-May-08 21:35 
GeneralRe: better buggy whips.... Pin
N-O-R-B-E-R-T at 6-May-08 21:53
memberN-O-R-B-E-R-T6-May-08 21:53 
GeneralRe: better buggy whips.... Pin
Wong Shao Voon at 6-May-08 22:15
memberWong Shao Voon6-May-08 22:15 
GeneralRe: better buggy whips.... Pin
Douglas R. Keesler at 7-May-08 17:54
memberDouglas R. Keesler7-May-08 17:54 
GeneralRe: better buggy whips.... Pin
robertjb20 at 7-May-08 4:43
memberrobertjb207-May-08 4:43 
GeneralRe: better buggy whips.... Pin
Douglas R. Keesler at 7-May-08 18:17
memberDouglas R. Keesler7-May-08 18:17 
GeneralRe: better buggy whips.... Pin
BC3Tech at 7-May-08 12:20
memberBC3Tech7-May-08 12:20 
GeneralRe: better buggy whips.... Pin
Stefan Melaet at 13-May-08 2:24
memberStefan Melaet13-May-08 2:24 
GeneralThe year 2106 Pin
Tak at 6-May-08 13:43
memberTak6-May-08 13:43 
GeneralRe: The year 2106 Pin
08989088 at 6-May-08 17:04
member089890886-May-08 17:04 

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
Web04 | 2.8.150427.1 | Last Updated 6 May 2008
Article Copyright 2008 by Ruchit S.
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid