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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]