5 ms·

The Year 2038 Problem

35 points by makimaki 18y ago

latortuga 18y ago
"...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 18y ago
  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 18y ago
    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 18y ago
      And most embedded code does not care about dates anyway.
  - deleted 18y ago
    [deleted]
  - sh1mmer 18y ago
    Isn't the real problem recompiling executables for which the source is lost or are so hopelessly mired in legacy production systems deploying them would be hell on earth. 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.
- extension 18y ago
  Actually, it wouldn't change anything since add/sub are the same for signed (2s comp) and unsigned ints and C will happily let you assign a signed literal to an unsigned variable. 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.
GavinB 18y ago
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.
- DaniFong 18y ago
  You mean the second coming of Jesus Christ, surely?
- tdavis 18y ago
  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 18y ago
    We still have Cobol and Fortran (and Lisp).
- ensignavenger 18y ago
  "29 years Starcraft will stop working!" 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!
snitko 18y ago
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.
- allenbrunson 18y ago
  i suspect that windows' low-level timekeeping is not based on time_t, the way unix is. windows has a bunch of stuff like the SYSTEMTIME struct that does not exist on unix-like operating systems and doesn't have the same vulnerabilities. so windows-only software is less likely to exhibit this problem. macosx/linux/unix is much more severely affected. 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.
- jwilliams 18y ago
  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 18y ago
    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 18y ago
      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).
waratuman 18y ago
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.
KevBurnsJr 18y ago
So what's the fix? Upgrade every machine to 64-bit? Did/do/will 16-bit machines have a similar problem?
- extension 18y ago
  heh if you wrote code that used a 16-bit time data type, it would be broken by the next day
goodkarma 18y ago
>> 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 18y ago
  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.

35 points by makimaki 18y ago

"...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 18y ago
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 18y ago
  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 18y ago
    And most embedded code does not care about dates anyway.
- deleted 18y ago
  [deleted]
- sh1mmer 18y ago
  Isn't the real problem recompiling executables for which the source is lost or are so hopelessly mired in legacy production systems deploying them would be hell on earth. 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.
extension 18y ago
Actually, it wouldn't change anything since add/sub are the same for signed (2s comp) and unsigned ints and C will happily let you assign a signed literal to an unsigned variable. 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.

GavinB 18y ago

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.

DaniFong 18y ago
You mean the second coming of Jesus Christ, surely?
tdavis 18y ago
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 18y ago
  We still have Cobol and Fortran (and Lisp).
ensignavenger 18y ago
"29 years Starcraft will stop working!" 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!

snitko 18y ago

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.

allenbrunson 18y ago
i suspect that windows' low-level timekeeping is not based on time_t, the way unix is. windows has a bunch of stuff like the SYSTEMTIME struct that does not exist on unix-like operating systems and doesn't have the same vulnerabilities. so windows-only software is less likely to exhibit this problem. macosx/linux/unix is much more severely affected. 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.
jwilliams 18y ago
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 18y ago
  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 18y ago
    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).

waratuman 18y ago

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.

KevBurnsJr 18y ago

So what's the fix? Upgrade every machine to 64-bit? Did/do/will 16-bit machines have a similar problem?

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

goodkarma 18y ago

>> 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 18y ago
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.