The Year 2038 Problem
pw1.netcom.com
pw1.netcom.com
however, microsoft's c/c++ compiler does indeed recognize time_t and related functions. any software that uses them will be subject to the 2038 problem.
Perhaps an SSL certificate thing? If you wind your clock forward enough it's past the expiry of SSL certificates.
This is almost certainly not a coincidence. In software that doesn't take the Y2K38 issue into account the expiration date would wrap around to an earlier date, causing the software to think the cert is invalid.
I'd be surprised if 2038 was the reason though - most certificates are very conservative about expiry.
You'd never have a cert that lasts to 2038 as there is a high probability that the cert would be cracked well before that date (i.e. even if it's brute-force, likely computers in "n" years time will be able to crack it).
http://tlrobinson.net/skitches/Keychain_Access-20090106-0009...
Good thing we have 28+ years to sort this out..
It seemed like it didn't really come into prominence until 1997 or so to me, but that's purely anecdotal.
But really, in all seriousness, the singularity will come in 2032 and we won't have to worry about any of this stuff.
This sounds like a serious problem, but when you consider how fast computer hardware and software grows and changes, I have a feeling there really won't be any 32 bit apps by then. I mean, christ, look at the past 30 years!
As I was reading the article, that was precisely the game I was thinking about- what if Star Craft stops working! Disaster- but perhaps StarCraft II will be out by then- and hopefully it will work!
I don't think that's how it works...
personally i think they should redefine time_t to be a signed 64-bit integer. a better solution, i think.
16-bit Windows only lasted 10 years. There is 30 years until the problem.
The biggest issue will be embedded code, but much of that may have failed/been replaced when 2038 rolls around.
That was the basic problem with Y2K no one expected them to live that long so upgrading them wasn't considered. This seems like the same retrofit issue, possibly with more warning and experience second time around.
You would just get some compiler warnings and maybe break the rare piece of code that multiplies negative time deltas.
What you have to fix are the operations that convert between time_t and some other representation and those are not going care about the data type.
Did/do/will 16-bit machines have a similar problem?