Gregory's Server
I'm slowly working on a new blog post. In the meantime, I've looked closer at the #y2k38 problem, and I'd like to share some observations with you.
It seems that the problem is mostly considered from the "overflow" in 32-bit programs angle — i.e. that we're suddenly going to move back in time from 2038 to 1901, and there will be some "funny" effects of that. However, in reality we're probably going to see different kinds of problems.
Firstly, `stat()` stops working on files whose timestamps can't be expressed in 32-bit `time_t` (the files can still be opened, though). It is quite counterintuitive; we usually assume that opening files is more restrictive. In the most absurd case, a program would be able to use a file only once. Once used, timestamps will get updated and `stat()` will start failing.
Secondly, `time()` returns an error. Many developers (myself included) doesn't even consider that `time()` can fail. Yet after 2038, every single call is going to return `-1`. What does that mean? A "well-written" software will just fail with an error. Other programs will just be "stuck" 1 second prior to midnight of December 31, 1969. And I believe that could be worse than returning an "overflowed" time counter, as every call will return the same value.
What could the consequences be? Clocks showing the same date and time all the time. Waiting loops based on wall clock time hanging immediately. Events never getting triggered. Clock-seeded pseudorandom number generators (`srand(time(NULL))`) always returning the same sequence of numbers.
This will affect all proprietary software on 32-bit platforms. If we wanted to play an old game, we're going to have quite a fight ahead of us. What's even worse, even faketime doesn't suffice here — it will adjust the time returned by `time()` calls, but not file timestamps.