Unix time to read 1234567890
- Thread starter Rosalind
- Start date
It's the end of the world!!!!!
No, that'll happen when the clock reaches 4815162342.
No, that'll happen when the clock reaches 4815162342.
Actually, it may very well become a problem long before that. Currently, on some Unix computers time is stored as a 32-bit signed integer representing the number of seconds since 00:00:00 on the 1st of January 1970. A variable using this format is typedef'ed as time_t.
At 03:14:07 on the 19th of January 2032, that number will be 2147483647.
At that point, when represented in binary that would be a 0 followed by 31 1's.
Increment that value by 1 and that binary becomes a 1 followed by 31 0's. That's a bad thing. That would mean that the number being represented is now -2147483648, leading many computer systems to believe that it is suddenly the 13th of December 1901.
There are lots of associated problems with fixing this. Although it is a fairly simple matter to redefine time_t as a 64-bit unsigned integer (which would allow you to store dates roughly 270 million years in to the future), you would also need to go back through all your old data (where the dates were stored as 32-bit numbers) and change the software that reads that data to understand that it need "upgrade" that data to using 64-bits.
No, that'll happen when the clock reaches 4815162342.
Actually, it'll be when the clock starts repeating 42 ...
Damn it! I thought we fixed this with the whole Y2K thing?No, that'll happen when the clock reaches 4815162342.
Actually, it may very well become a problem long before that. Currently, on some Unix computers time is stored as a 32-bit signed integer representing the number of seconds since 00:00:00 on the 1st of January 1970. A variable using this format is typedef'ed as time_t.
At 03:14:07 on the 19th of January 2032, that number will be 2147483647.
At that point, when represented in binary that would be a 0 followed by 31 1's.
Increment that value by 1 and that binary becomes a 1 followed by 31 0's. That's a bad thing. That would mean that the number being represented is now -2147483648, leading many computer systems to believe that it is suddenly the 13th of December 1901.
There are lots of associated problems with fixing this. Although it is a fairly simple matter to redefine time_t as a 64-bit unsigned integer (which would allow you to store dates roughly 270 million years in to the future), you would also need to go back through all your old data (where the dates were stored as 32-bit numbers) and change the software that reads that data to understand that it need "upgrade" that data to using 64-bits.
Damn it! I thought we fixed this with the whole Y2K thing?
The good news is that the problems are a lot more predictable than Y2K and they're fairly easy to fix.
I suspect that by 2032 our computer systems won't use UNIX so we'll probably be safe.
Unix is a damned good operating system that has evolved over the past 20+ years. It stands to reason that the manner in which time is computed and stored will have been changed long before 2032.
I suspect current UNIX systems will be patched and upgraded. And I'm quite sure the UNIX operating system will not be gone by the year 2032.
Similar threads
