1234567890 on Black Friday
Strange things tend to happen when notable timestamps are reached. It may not seem like it would be much of a problem, but the whole Y2K concern was a result of the fear that systems and software that were coded to handle two digit years and not four digit years would have major problems with the roll over from 1999 to 2000, seeing 00 as representing 1900, and not 2000. More succinctly, it was a problem of how to handle systems that were not designed to handle anything other than the century in which they were created.
Another unique timestamp will be encountered in a little over a week's time, with POSIX time reaching 1234567890 at 23:31:30 UTC on February 13th, 2009. Other than making for an interesting number it should give programmers and QA staff something to think about. Are there any test cases or unexpected code entry points that might have been left behind and which can be triggered by the above timestamp (which would make for an easy to remember test case)?
Having 1234567890 go past might be a useful hint that timekeeping problems will eventually be an issue for most software. Just as many of the developers of software affected by Y2K hadn't considered their software still being in use at the change of century, there is still a lot of software in use that is either having problems due to time and date related errors, or will soon be.
If you are having trouble telling when the 1234567890 time is going to be, the following is a helpful site, where you can see just how long it is until that time, or if it has already been.
4 February 2009
Social bookmark this page at eKstreme.
Alternatively, Bookmark or Share via AddThis
Do you like how we cover Information Security news? How about checking out our company services, delivered the same way our news is.
Let our Free OS X Screen Saver deliver the latest security alerts and commentary to your desktop when you're not at your system.
Comments will soon be available for registered users.
Subscribe to our feed.