-
Notifications
You must be signed in to change notification settings - Fork 24
Why Bother?
If 2038 is still 30 years away, why bother fixing it now? Well, sometimes things happen in the future, and we like to know when that will be. Sometimes things need to be scheduled more than 30 years from now, like a 30 year mortgage. Or a 30 year savings bond. Or perhaps some sort of death clock.
This problem will only become worse as time goes on, which is bad because...
One of the most frustrating parts of being a software developer is that there will always be somebody who never upgrades. In fact, there will be A LOT of people who never upgrade. For example, a good chunk of the Perl community is still using 5.6.1 which came out seven years ago.
So if we start fixing the 2038 bug now, maybe, just maybe, by 2020 when the problem becomes acute people will have already upgraded to 2038 clean programs.
A 64 bit CPU doesn't mean y2038 clean.
For example, your shiny new Apple computer has a 64 bit processor in it. But the operating system is still operating with 32 bit integers and a 32 bit time_t and has a 2038 bug. Why?
When you change the integer size you need to recompile all your software. Then Mac applications would have to ship 32 bit and 64 bit versions. Apple has dealt with this sort of thing gracefully several times in the past ("fat binaries" for the Motorola -> PowerPC switch, "universal binaries" for the PowerPC -> Intel switch), but it's still a painful and buggy process for both developer and user. (Note: OS X 10.6 appears to have made the jump to 64 bit software).
I don't blame them for not thinking it worth the effort. Windows has had 64 bit versions since the early nineties, and very few people use them. Its a lot of work, especially in twitchy, hyper-optimized driver code.
And just because you're using a shiny new 64 bit processor doesn't mean everyone else will. 32 bit processors will remain cheap and plentiful, not just in PCs and old hardware, but in your car, your phone, your watch, your TV, your DVD player...
I looked around and couldn't find anything that...
A) Handled time zones b) Matched the time.h interface 3) Didn't ship its own time zone database D) Is portable e) Is freely redistributable
For example, libtai is awesome, but it doesn't support time zones and doesn't look much like time.h. I could pull code from BSD, but it's not portable.
If there is such a thing, please let us know and we'll gladly scrap this whole project!
Let's say they are. At what point in the future do they become meaningless? What's the largest time_t you should be able to put into localtime() and gmtime() before your program simply stops working or starts returning nonsense? I can guarantee you, whatever you think is reasonable someone will want to go beyond. Library code should not unjustly limit the designs of the programmer. 2038 is obviously too small. The next required limit is 300 billion years. Anything between is an artificial limit.
And they're not meaningless, not even time zones. Why? Because time zones, distorted as they are, are still a representation of where the sun is in the sky. And that's handy information to know. So handy that well done 64 bit time zone databases use solar noon to determine a city's time zone before there were time zones.
Most 64 bit time.h's have major flaws after 248. But even I think that's time enough.