Messages in this thread | | | Date | Fri, 13 May 2005 16:36:23 -0400 | From | Bill Davidsen <> | Subject | Re: Y2K-like bug to hit Linux computers! - Info of the day |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |