The Year 2038 Problem

[cos]

[ Context for noncomputergeeks: A lot of computer systems based on Unix or Unix-derived software store times as number of seconds since the beginning of 1970. Midnight on Dec 31 1969 / Jan 1 1970, is "0" time. If you use a signed 32 bit number to store time, the highest possible value is in 2038; over the past decade, the computer world has been shifting from 32 bit to 64 bit systems, but there are still lots of data formats based on storing 32 bit values. ]

I used to think we have plenty of time to convert all of our computing and data formats to 64 bit times before the year 2038. But an email discussion at work made me look at it in a new light:

"Back when I worked at a bank, we started seeing bugs in 2008 for 30 year mortgages."

Comments

[nacht_musik]

Yeah, I fixed a Y2038 bug last year at work for some software that handles the expiration dates of potentially-long-lived SSL certs.

[ron_newman]

Why not just retroactively redeclare this field to be unsigned? They we can kick the problem down the road another 68 years.

[ckd]

That would break anything that has to deal with dates before 1970. Since that includes birth dates for anyone who'll be older than 68 in 2038, it's better to just fix the code for real and use a 64-bit time_t.

[sparr0.livejournal.com]

Even doing that requires updating/patching/recompiling the software.

[cos]

Negative numbers get used to represent dates before 1970, so if you retroactively redefine what that means, suddenly you think the database entry for the person born in 1965 says she'll be born in the future.

[dougo.livejournal.com]

But don't most databases store dates as strings?

[cos]

I don't know how you'd go about figuring "most" since as far as I'm aware there's no international survey of stored data. It is certainly true that there is an unfathomably huge amount of stored data out there in formats that use 32 bit signed unix dates.

[jered]

I almost never see date fields as strings. The type coercion when doing date operations would be monstrous!

64-bit time_t is the right thing to do, but I bet we'll see all sorts of ugliness like is in the messages database on the iPhone -- there'll be a bit flag that specifies a different epoch time 0. Epoch 0 starts in 1970, epoch 1 starts in 2038...

[dougo.livejournal.com]

Sorry, I should have said "DBMSes". I was thinking that PostgreSQL, MySQL, and SQLite all store dates as strings, but now that I look into it, PG uses 4 bytes for the date datatype. I guess I was thrown off by the fact that I always get strings back from a query. (And I have no idea what Oracle, MS, etc do.)

Although, the Y2K problem was due to storing dates as (too short) strings, so at least those databases won't break again until 2100...

[plymouth.livejournal.com]

whoaaa. I never thought of it that way before! wackypants.

[eirias.livejournal.com]

Two things!

1) I love that "noncomputergeeks" can be multiply parsed.

2) It's interesting that this problem is less hyped in the popular press -- I assume that's in part because it doesn't have a Nice Round Number associated with it, like Y2K did.

[luckylefty.livejournal.com]

It's less hyped in the popular press because it's 26 years from now. I think there's at least as much discussion of this in the popular press today as there was discussion of the Y2K problem in 1974.

[eirias.livejournal.com]

Oh, piffle. :) Yes, you're right -- I'm sure that's part of it too. But it wouldn't surprise me if it got to be, say, 2036 and still it wasn't on the radar of the nonnerd. On the other hand, people are all excited about the world ending in December, so maybe I'm wrong. (But that too has a strange near-symmetry -- 12/21/2012.)

[rkt.livejournal.com]

pretty sure there's no "party like it's 2037" (yet).

[ocschwar.livejournal.com]

I am so glad the bug is starting to bite right now.

Thank you, Unix-using mortgage lenders.