|Unix Clock Ticks Down To 2038 Problem|
|Written by Harry Fairhead|
|Sunday, 24 September 2023|
Remember the year 2K catastrophe? Well no, neither do I, cos we had more or less fixed the problem by the time the dreaded date arrived. Soon after people were happy to point out that we had a whole 38 years to the next problem. But how long is it now?
The s32 unix clock is a really nice display of how big a 32-bit unsigned value really is. Take the 32 bit value and divide it into four bytes and represent those as hex. Next draw a clock with four hands - one for each hex value counting from 00 to FF. Take the Unix time and represent it on the clock - sit back and watch. When the little red hand points down to 80, the epochalypse is upon us:
It will happen at 03:14:07 UTC on 19 January 2038.
To me it looks a long way off and that we're getting there remarkably slowly, but then I'm old enough for it really not to be my problem. It almost certainly seemed like that when the original Unix OS was commissioned and date and time was measured from its creation date - the Unix epoch (00:00:00 UTC on 1 January 1970) as a count of seconds stored in a 32-bit signed integer. Negative values represent time before the epoch and positive time after. At the time 32-bits was a lot of bits to throw at the problem, given their cost and scarcity.
With so long to confront the problem most modern Unix/Linux systems have been upgraded to 64-bit time.
Is this enough?
It will take roughly 300 billion years before we reach the Y300B problem, more than 20 time the estimated age to date of the universe.
So it really does look as if 64 bits is enough.
or email your comment to: email@example.com
|Last Updated ( Sunday, 24 September 2023 )|