Computerpackage and Entertainment

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.

Collapse

#include

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 :

Collapse

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.

Collapse

#!/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 <>

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.

Remember the turn of the millennium? Whilst many of us were counting down the seconds until midnight, there were network administrators across the globe with their fingers crossed hoping their computer systems will still be working after the new millennium kicked in.

The millennium bug was the result of early computer pioneers designing systems with only two digits to represent the time as computer memory was very scarce at the time. The problem didn't arise because of the turn of the millennium, it arose because it was the end of the century and two digit year flicked around to 00 (which the machines assume was 1900)

Fortunately by the turn of the millennium most computers were updated and enough precautions were taken that meant that the Y2K bug, as it became known, didn't cause the widespread havoc it was first feared.

However, the Y2K bug is not the only time related problem that computer systems can be expected to face, another problem with the way computers tell the time has been realised and many more machines will be affected in 2038.

The Unix Millennium Bug (or Y2K38) is similar to the original bug in that it is a problem connected with the way computers tell the time. The 2038 problem will occur because most machines use a 32 bit integer to calculate the time. This 32 bit number is set from the number of seconds from 1 January 1970, but because the number is limited to 32 digits by 2038 there will be no more digits left to deal with the advance of time.

To solve this problem, many systems and languages have switched to a 64-bit version, or supplied alternatives which are 64-bit and as the problem will not occur for nearly three decades there is plenty of time to ensure all computer systems can be protected.

However, these problems with timestamps are not the only time related errors that can occur on a computer network. One of the most common causes of computer network errors is lack of time synchronization. Failing to ensure each machine is running at an identical time using a NTP time server can result in data being lost, the network being vulnerable to attack from malicious users and can cause all sorts of errors such as emails arriving before they have been sent.

To ensure your computer network is adequately synchronized an external NTP time server is recommended.

Richard N Williams is a technical author and specialist in atomic clocks, telecommunications, NTP and network time synchronisation helping to develop dedicated NTP clocks. Please visit us for more information about an NTP server or other NTP time server solutions.