Re: Y2K-like bug to hit Linux computers! - Info of the day

From: Bill Davidsen
Date: Fri May 13 2005 - 15:39:15 EST


Richard B. Johnson wrote:

It would be good if the doom-sayers actually tried before then lied.....

Just in case anybody wants to try it:

int main()
{
int x = 0x7fffff00;
stime(&x);
}

Script started on Mon 18 Jan 2038 10:12:32 PM EST
[root@chaos root]# while true ; do date ; sleep 1 ; done
Mon Jan 18 22:12:44 EST 2038
Mon Jan 18 22:12:45 EST 2038
Mon Jan 18 22:12:46 EST 2038
Mon Jan 18 22:12:47 EST 2038
Mon Jan 18 22:12:48 EST 2038
[SNIPPED...]
Mon Jan 18 22:14:01 EST 2038
Mon Jan 18 22:14:02 EST 2038
Mon Jan 18 22:14:03 EST 2038
Mon Jan 18 22:14:04 EST 2038
Mon Jan 18 22:14:05 EST 2038
Mon Jan 18 22:14:06 EST 2038
Mon Jan 18 22:14:07 EST 2038
Fri Dec 13 15:46:09 EST 1901
^^^^^ are UTC and GMT that far apart? Leap seconds? WTF?
Fri Dec 13 15:46:10 EST 1901
Fri Dec 13 15:46:11 EST 1901
Fri Dec 13 15:46:12 EST 1901
Fri Dec 13 15:46:13 EST 1901
Fri Dec 13 15:46:14 EST 1901
Fri Dec 13 15:46:15 EST 1901
Fri Dec 13 15:46:16 EST 1901
Fri Dec 13 15:46:17 EST 1901
Fri Dec 13 15:46:18 EST 1901
Fri Dec 13 15:46:19 EST 1901

[root@chaos root]# exit

Script done on Fri 13 Dec 1901 03:46:44 PM EST

As you can see, the machine still runs. There was a little
hickup in the 'sleep 1' it slept more than a second.

Remember to `rdate` your computer before you do any serious
work. The file-dates correctly show the new, before Unix, time and
date.

Good point. Given current firewalls, I wouldn't be surprised if rdate fails and ntpdate is needed, or at least resetting the system clock from HW.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/