The Y2k date issue was caused by the fact that computers were programmed to add a two digit number to some epoch (most notably 1900). So 100 became 00 and was added to 1900 to become 1900. This was corrected by increasing the number of digits used to store the year. The next date issue will occur in 2038 when the date field (a 32 bit signed integer) runs out of room to hold the number of milliseconds since the epoch. The fix for this will be a little more elaborate and will most likely involve the use of 64 bit integer.

Here is a perl script to see what time your computer will return when the Y2k38 hits. It will return the second just before and just after the event.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#! /usr/bin/perl -w
 
use strict;
use warnings;
 
# Use POSIX (Portable Operating System Interface),
use POSIX;
 
# Set Time Zone to GMT (Greenwich Mean Time)
$ENV{'TZ'} = "GMT";
 
my $ticks;
 
# Event occurs at 2147483648 seconds
for ($ticks = 2147483647; $ticks <= 2147483649; $ticks++)
{
    print ctime($ticks);
}

Depending on their epoch (Unix uses Jan 1 1970), different OSes will have different times with the Y2k38 bug hits.

Unix:

Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

Windows:

Mon Jan 18 21:14:07 2038

Linux happily continues on with the incorrect time, Windows however appears to stop returning results.

References:
Y2K
Y2k38

Leave a Reply

You must be logged in to post a comment.