Slashdot Mirror

← Back to Stories (view on slashdot.org)

February 13th, UNIX Time Will Reach 1234567890

Posted by timothy on from the less-often-than-a-stopped-clock-is-right dept.

mikesd81 writes "Over at Linux Magazine Online, Jon maddog Hall writes that on Friday the 13th, 2009 at 11:31:30pm UTC UNIX time will reach 1,234,567,890. This will be Friday, February 13th at 1831 and 30 seconds EST. Matias Palomec has a perl script you an use to see what time that will be for you: perl -e 'print scalar localtime(1234567890),"\n";' Now, while this is not the UNIX epoch, Alan Cox does assure us that Linux is now working on 64-bit time, and the UNIX epoch 'roll-over' would happen about the time that the sun burnt out."

1 of 376 comments (clear)

  1. Must be a slow news day.. by mysidia · · Score: 1, Flamebait

    I mean seriously... why is 1234567890 such a special timestamp? Where was the article when we crossed 123456789 ? :)

    As for Linux using 64-bit time, that's great, but many applications still were compiled with a 32-bit time_t

    Or use 32-bit integers to represent the time saved in binary DB structures, where it's not so trivial to convert.

    The OS itself may live past the 2038 32-bit time_t rollover, but the same cannot be said about all mission-critical apps that may be running on top of the Linux OS.

    An OS is nothing without database apps, business apps, etc, some of which source code may not be available for, some of which may be unsupported abandonware by the time 2038 rolls around.

    For example, do MySQL and postgreSQL use 64-bit date values exclusively now?

    What about apps that were already written and use ordinary ints to hold time_t values? They'll have issues just like the Year 2000 issues that were a problem 10 years ago.