
The Year 2038 Problem - makimaki
http://pw1.netcom.com/~rogermw/Y2038.html
======
snitko
Okay, so I changed the year to 2039, started WindowsXP in VirtualBox. Nothing
happend. Opened Excel, typed in some time-related functions (like NOW), worked
fine. And just by the time I was going to post this message ending with "What
is wrong with it, I want some blue screen people" I simply couldn't log in
with my LiveJournal openID (not sure if this is HN's or LJ's fault), so seems
like this time thing really works.

~~~
jwilliams
_I simply couldn't log in with my LiveJournal openID_

Perhaps an SSL certificate thing? If you wind your clock forward enough it's
past the expiry of SSL certificates.

~~~
tlrobinson
Yeah that's likely the issue. Actually, looking at all the root CA certs on my
computer (OS X, look in Keychain.app if you're curious) every single one of
them (except one) expires in 2037 or earlier.

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.

~~~
jwilliams
Ah ok - yeah, I've hit that issue in testing before.

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).

~~~
tlrobinson
I would have thought that too, except there's a bunch of certs with
expirations all the way up to 2037 at which point they abruptly stop (except
for the one 2040)...

[http://tlrobinson.net/skitches/Keychain_Access-20090106-0009...](http://tlrobinson.net/skitches/Keychain_Access-20090106-000936.png)

------
goodkarma
>> So, if all goes normally, 19-January-2038 will suddenly become
13-December-1901 in every time_t across the globe, and every date calculation
based on this figure will go haywire.

Good thing we have 28+ years to sort this out..

~~~
icey
Any software historians out there? How much heads-up did we have for the whole
Y2K thing?

It seemed like it didn't really come into prominence until 1997 or so to me,
but that's purely anecdotal.

------
GavinB
Quick Ma, get back into the Y2K bunker! In 29 years Starcraft will stop
working!

But really, in all seriousness, the singularity will come in 2032 and we won't
have to worry about any of this stuff.

~~~
tdavis
A joke about Starcraft not working is a very inappropriate one! Although, as
long as Starcraft 2 works (and is released by then), we should be safe.

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!

~~~
eru
We still have Cobol and Fortran (and Lisp).

------
waratuman
I've already run into a problem with this on one of the sites I worked on.
Fortunately that date wasn't to important in that case and we settled leaving
the date somewhere in 2037 for the time being.

------
latortuga
"...re-define time_t as an unsigned integer instead of a signed integer...This
doubles the range of numbers it can store."

I don't think that's how it works...

~~~
allenbrunson
it would double the range of _positive_ integers it can store. that would mean
no more "cheating," and using negative values to represent times before 1970.

personally i think they should redefine time_t to be a signed 64-bit integer.
a better solution, i think.

~~~
likpok
IIRC 64-bit Linux does this. As 64-bit becomes more prevalent, this may become
a non-issue (Windows 7 was supposedly going to be 64-bit only, and one of the
next releases may make this true).

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.

~~~
eru
And most embedded code does not care about dates anyway.

------
KevBurnsJr
So what's the fix? Upgrade every machine to 64-bit?

Did/do/will 16-bit machines have a similar problem?

~~~
extension
heh if you wrote code that used a 16-bit time data type, it would be broken by
the next day

