For those who already played with timestamps, you know that they are limited to whatever you set your time_t type to.
On most 32bits systems, timestamps are limited to 2^31 because time_t is signed (to allow dates before January 1st 1970). This means that you cannot go after a certain date.. which is:
2038-01-19 04:14:07.
I studied a lot this potential problem, the Y2038 problem. It won’t happen just on year 2038, but 19 days later… however some systems are already affected.
I’ll take as an example the case of Orange France, a mobile operator (also ISP and a lot of other things).
This website claims I have a “multimedia option” available until… January 19th 2038. This looks a lot like Y2038-Bug. The point there is not to have everyone run everywhere because we’re going to run out of timestamps. Nope. Most “recent” UNIX systems now use 64bit signed integers for time_t, meaning this can go for a long long time (I can represent dates in year 35,680,317 without problem). It’s just a matter of stressing people that 32bits is dead, and it’s already time to switch to 64bits if you didn’t yet, because this kind of bug will happen more and more.
Another example would be domain names. You are allowed to renew a domain for up to 10 years. This means that people providing domain names will have to support 64bits integer on January 19th 2028, which is less than 20 years from now. Don’t laugh, it’s going to happen before you even notice it, and we’ll start seeing people’s domain becoming “expired” because they renewed over year 2038.
All my servers are 100% 64bits, and I hope most people will switch to 64bits on servers (if not already done).
