Year 2038 problem

http://en.wikipedia.org/wiki/Year_2038_problem

by areski • 13 years ago

194 108 13 years ago

en.wikipedia.org

api• 13 years ago

Most 64-bit systems have a 64-bit time_t, so this won't affect them. Some 32-bit systems have also shifted to a 64-bit time_t. But it will be an issue that'll require a lot of recompiling and patching of ancient legacy stuff.

vidarh• 13 years ago

Even on 64 bit platforms with 64 bit time_t you are assuming that time is always stored in time_t, and never stored in or exchanged with systems that still use 32 bit time values. That's by no means a safe assumption.

r00fus• 13 years ago

So there's the rub.

It's all the integration/glue code that's the problem.

The dark matter of the programming world.

0x02• 13 years ago

Think about all the file formats and network protocols that are designed for a 32bit time_t.

There will be a LOT of patching.

danielweber• 13 years ago

OpenBSD is in the process of doing an upgrade to 64-bit time_t. Well, of figuring out the best way to do it. They seem to have most of it worked out, it's just a question of when to pull the trigger.

angersock2• 13 years ago

When to pull the trigger... sometime around new year's day on 1970?

lucb1e• 13 years ago

Unsigned integers will get you going till the year 2106, that could be an easy hotfix if you don't have to store datetimes before 1970.

Using 64-bit integers is overkill, they will work till the year 584bln[1] and it's twice as much data for every timestamp. Adding one byte (5-byte integers) is uncommon, but that supports the year 36000 already, so it would be more than enough.

[1] In full, till the year 584 942 419 325.

lucian1900• 13 years ago

It's not like timestamps are very common in memory. And having them aligned would possibly be more valuable than a small reduction in memory.

swombat• 13 years ago

For the comic symmetry of the universe, I hope some digital archeologist picks up this comment in 3599 and curses us under his breath.

thomasahle• 13 years ago

Or define your 64bit timestamp to be in nanoseconds, in which case it will only last till year 2555.

masklinn• 13 years ago

> Using 64-bit integers is overkill, they will work till the year 584bln[1]

Yes because we have so little memory and so many timestamps to store that scrounging on the size of timestamps is highly important and absolutely not something which has been a pain in the ass half a dozen times in the short lifespan of computers.

Wait, we don't and it has.

FigBug• 13 years ago

Most languages don't have 5 byte types. Even if you make a struct with a 32bit int and an 8bit int it's get padded to 64bits. Additional complexity for no savings.

otikik• 13 years ago

640kB ought to be enough for everyone, right.

Dewie• 13 years ago

32 bit integers are probably the most commonly used size for integers in contemporary programming, even though they seldom will need anything near that kind of capacity. Is it really necessary to be a miser with memory when it comes to this?

PavlovsCat• 13 years ago

I don't mind doubling the size that much, but why not have milliseconds instead of seconds? 500+ billion years is just silly.. 500 million years ought to be enough for any civilization.

ygra• 13 years ago

Windows uses 100-ns intervals since 1601 (start of the current 400-year cycle of the Gregorian calendar at the point where NT was designed) which offers good accuracy and should last for the foreseeable future.

Ovid4• 13 years ago

Actually, a friend of mine has written a fix for it (https://github.com/schwern/y2038) in C. Just use the new functions and you're probably good. It's under an MIT license, so have fun with it.

Me? I'm waiting for the idiots who claim it's a worldwide geek conspiracy à la Y2K. Here's a haiku (senryu) I wrote for that:

    Is Y2K real?
    The problem's being solved by
    Men who can't find dates.

0x02• 13 years ago

This won't help you if you need to interface with existing files or protocols...

Ovid4• 13 years ago

Yes, that's a good point. At least it's a start (though I'm dubious about some assumptions the code makes regarding time zones).

btilly2• 13 years ago

Change all unsigned ints that store time to signed.

In another 68 years or so, change them all back to unsigned.

:-)

codeulike• 13 years ago

I hope humans are still around to deal with the eventual Y10K problem.

ck23• 13 years ago

I like to make sure future programmers have work to get paid for so I always make sure my databases use 32-bit integers for time :-)

Seriously though, in 20-25 years I think we cannot even fathom how fast and parallel databases will be, an ALTER will probably take a few seconds on a billion row table.

Ovid4• 13 years ago

As someone who had some fun (er, not) during the Y2K debacle, I can promise you it's a lot more than just altering databases or patching a few bits of code. Sometimes the code is impossible to understand. For example, one program named all the variables after types of alcohol and had lines like:

    compute martini equals gin plus vermouth.

(Yeah, I used to hack COBOL, too).

Other times there would be absolutely critical systems which were developed, but were tucked away on an unknown server and we'd find out about them at the last minute and panic trying to figure out if they would work correctly.

And if you get into languages who have severe bondage and discipline on datatypes, finding out that the subtly altered data that works in one system is blowing up another one just isn't fun.

What's worse: sometimes the logic just assumes that dates can't be past a certain time. Ooh, let's set the date to maxint of this data type and use that as the cutoff in our code. This code won't exist then, right? Naturally, the tests hard-code a datetime in them and it won't show up even when clocks are deliberately set forward to test the code. Of course, I've hacked on code that was written before I was born, so the whole "this code won't exist then" actually means "I won't be working here then".

ck23• 13 years ago

Yeah I figure it might be more complex for other code but I seriously only use 32bits in the database for time while we are still using mechanical storage.

The actual code for time will work fine with 64bit integers, well once it's compiled correctly in a 64bit environment which is a huge percentage of servers right now.

I'm just too old school to waste 4 bytes on millions of rows (and for index storage which does bloat) when I am not dealing with future dates.

Right now ALTER in most SQL databases is kinda slow and not done in parallel but that is certainly going to change and next-gen SSD in this decade will also change everything.

MartinCron• 13 years ago

compute martini equals gin plus vermouth

That's the most terrible code I've ever read. There's no units, it doesn't specify the ratio of gin to vermouth. That's not a martini, that's a mess.

hobs• 13 years ago

Right, but as the computer's scale, so do the datasets. We are like the goldfish of information storage, give us a bigger disk, we will give you more data.

normalocity• 13 years ago

3:14 - Pi time in Jan. 2038.

Get a Pi(e) and enjoy eating it as the world collapses...or when the world is just fine you will have just enjoyed a delicious pie.

radimm• 13 years ago

I remember times of y2k and thinking both how 2038 is far away and that none of the system we use will be there :) 13 years later (1/3 of the time) I'm not longer that sure...

majke• 13 years ago

You can use `libfaketime` to test your software:

* https://github.com/wolfcw/libfaketime

Shameless plug: my project `fluxcapacitor` may also be useful for testing:

* https://github.com/majek/fluxcapacitor

Aissen• 13 years ago

fluxcapacitor looks like 'macfly': https://github.com/haypo/macfly

ccozan• 13 years ago

I can only recommend libfaketime. It great to test all kind of software, which either depends on some time of day or, alternatively ( but not recommended! ) to circumvent some other software with a built in license expire time.

apaprocki5• 13 years ago

Just wanted to point out that this has affected software revolving around finance for some time now. Historical data goes back into the 1800s and there are bonds with very, very long horizons (100-year or approaching it). The last time I checked on Bloomberg I believe the latest maturity date I could find in the system was sometime in 2089. I think the industries that have had to deal with this already will not be very affected by 2038.

edit: Link to C++ N3344 paper we wrote, describing how we represent dates (times/datetimes are similar): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n334...

edit2: Anyone interested in examples -- on the early side:

    ISIN GB0000436070, UK Gilt, issued 1853, perpetual annuity

On the future side, things have changed since I last looked. Example bonds with the latest dates I can find are:

    ISIN XS0560190901, Dong Energy A/S, callable 06/01/3010
    ISIN US786581AA66, HSBC Holdings Luxembourg SA, callable 10/15/2997

kevindication• 13 years ago

Right, but just because you have a data type that can handle a date that far in the future does not imply that you have fixed your OS and supporting software to be able to handle the day when the system time rolls over.

apaprocki5• 13 years ago

Yes, it really just depends how much your software stack depends on the OS and higher level OS-related services. If your software is not coupled with other points of failure in OS user-land, then you really only need a single entry point to get network-sync'd 64-bit time_t and then everything else in the stack can be built around vocabulary data types such as these. These are the types that are transmitted in protocols, serialized to files, etc.

HorizonXP2• 13 years ago

That is insanely cool. How does that even work? Does the original bond issuer even exist anymore? If I'm holding a bond with a call date of 3010, what do you even do with that?

apaprocki5• 13 years ago

These bonds have scheduled payments so the idea is that you are earning yield on your investment for 1,000 years. You're getting paid as time rolls on -- you're not waiting for the maturity date. All the parameters of the bond indicate how risky the market sees the investment. If Joe Nobody wants to issue a 1,000 year bond, the market would demand an appropriate rate given the risk involved. Most likely, it would never be issued because no one would be safe with that level of risk. I'm guessing the market considers HSBC Luxembourg pretty safe.

twistedpair• 13 years ago

The 2070 problem is going to be much more serious. The only stuff still running code then will be stuff we're terrified to touch like reactor control systems and such.

I hope I live to see it.

Someone• 13 years ago

Not bonds, but http://en.wikipedia.org/wiki/999-year_lease shows leases of land that run for 999 years.

jrabone3• 13 years ago

You leave that bug alone, that's my retirement policy that is.

mkopinsky• 13 years ago

Your "pull me out of retirement to fix mission critical bugs" policy, rather.

angersock2• 13 years ago

That's funny, where I'm from the policy is called "jQuery".

Graham24• 13 years ago

The system I'm working on counts time as an unsigned 32-bit int starting in 1900 (don't ask). I think we fail in 2036 and that's a mere 23 years time.

It does really annoy me when idiots talk about the Y2K problem as being nothing at all and just a hyped-up non-event.

I for one, worked on fixes for Y2K and it all went seamlessly because we (collectivly) worked hard and got it right and no reactors/missles blew up and the banks did not fail.

johansch2• 13 years ago

You might find this thing I found on the web just now amusing:

http://forums.buffalotech.com/t5/Storage/CloudStor-Date-Time...

"Installed a new CloudStor 2.0TB Pro and no matter what I try on the System...Date/Time settings (manual or automatic), the device date (and ultimately new folder create dates) set themselves back to February 7, 2036 1:28AM. My device timezone is set for UTC-05:00 Eastern Time (US & Canana)."

glhaynes5• 13 years ago

Same thing whenever those "useless" organizations like the World Health Organization monitor/quarantine people and animals showing new strains of the flu. Afterward, I inevitably hear a "well, that sure was a dud... all that expense and trouble over a flu that didn't turn out to be a big deal. They're just trying to scare us to justify their jobs." Infuriating.

guscost• 13 years ago

Were people actually expecting nuclear reactors to "blow up" because of a software problem?

http://en.wikipedia.org/wiki/Passive_nuclear_safety

cleaver2• 13 years ago

I tried to register a Year 2038 related domain in the late 90's. Anything good was taken.

I assume the more interesting aspect of Y2038 will be the societal... Will we all be stocking our bunkers with 5 gallon pails of dried pinto beans and arming our personal attack drones?

I'd like to think we'll be a bit wiser, but somehow doubt it. Software is full of date related bugs and fails all the time. The world didn't end before, during, or after Y2K. I don't think it's ending in 2038.

umsm• 13 years ago

I dont think you looked hard enough. :) The late 90s to about 2004 most good domains were being registered. Now we have to settle for foreign TLDs.

nwh• 13 years ago

I wouldn't worry too much. Soon we'll have .horse and .melbourne, all our TLD problems will be behind us.

astrodust2• 13 years ago

In the late 1990s you could still get domains with the names of major corporations because they were asleep at the wheel.

In the early 1990s you could get four letter domains and you could get them for free. There was no registration fee until around 1995.

elliottcarlson• 13 years ago

For PHP developers - date(), mktime() and strtotime() (as well as other functions) use 32bit signed integers for storing the date representation (except in some instances of a 64bit version of PHP on a 64bit OS), which is not y2k38 safe. It is preferred to use the DateTime class available in 5.2 and above which stores the date in a 64bit signed integer. There are other reasons to use the DateTime class as well - and it should generally be best practice to move away from date(), mktime(), strtotime() and other similiar functionality.

DanielShir• 13 years ago

This bug is my retirement fund :) Just like those COBOL guys back in 2000.

yoster• 13 years ago

Rerun of Y2K...

Eva_Peron• 13 years ago

does anyone have a start-up dedicated to solving this issue? something like an Initech for the 2038 bug? If not someone should.

TorKlingberg• 13 years ago

We should take the time to appreciate the people who choose to design text based protocols like SMTP and HTTP. They may be a little inefficient, but at least they don't suffer from arbitrary numerical limits like this.

astrodust2• 13 years ago

Using text was largely a way to make implementation easier, more human readable, and also conveniently avoid endian issues.

The arbitrary numerical limits are usually in the implementation, as many a buffer overflow bug as demonstrated.

anonymouz• 13 years ago

But the point is that the implementations can be fixed, one by one, without breaking the protocol.

pilif• 13 years ago

I think a much bigger problem than old software on 32 bit machines is the fact that some (binary) protocols use 32 bit integers to encode dates. That means that even when hardware and OSes get updated and even if servers or clients are maintained, stuff will still go wrong when the protocols are wrong.

So keeping up to date software might not be enough. We'll also have to pressure our peers to update and to adapt new protocol versions (that might have other changes in addition to just the widening of the timestamps)

stephengillie• 13 years ago

http://xkcd.com/607/

Dylan168074• 13 years ago

As long as you're able to update the software, it's easy to reinterpret the protocol as unsigned and get most of a century of extra time to worry about it. I don't think that's as big of a problem.

Heck, you can let it wrap forever and interpret timestamps as 'now plus or minus 50 years'.

emeidi• 13 years ago

I was there when Y2k happened! Alas, nothing happened except I was suffering from a huge hangover the very next morning.

mark-r• 13 years ago

I ended up with a gas station receipt that said "1/1/100". That was the extent of it.

jtwigg• 13 years ago

watch out for the Year 292,277,026,596 problem

astangl• 13 years ago

I put a (semi tongue-in-cheek) comment in some billing system code I wrote 8 years or so ago, pointing out a date overflow problem, something like Y292277026596 (can't remember the exact year now, but the comment was accurate). Comment went on to say that if the system was still in use at that time, then I would fix the problem.

I expected to be called out for this comment some day, but never have -- makes me wonder how often people read through code.

markhelo• 13 years ago

I own 2038K.com, if anyone has interesting ideas on what to do with it besides making money from ADS, let me know. I bought it as a retirement hedge with the evil plan to drum up doomsday scenarios to drive traffic. Wait, I am sure the media will take care of that for me when the date approaches.

njharman• 13 years ago

Countdown Timer. Should underflow at the last second, of course.

ryanthejuggler• 13 years ago

"Other automotive safety systems include anti-lock braking system (ABS), electronic stability control (ESC/ESP), traction control (TCS) and automatic four-wheel drive."

So anti-lock brakes are going to stop working after the wraparound? Seems to me that either (a) they're relying on code that they shouldn't--why should ABS depend on date and time? or (b) the article is just giving examples of embedded systems that could fail.

If case (a) is true, I imagine (or would like to think) that they're just using the timestamp to perform some simple physics computations of how to control the brakes. If this is the case, they could just use the uptime of the processor instead. Then they would only bump into this issue if the car ran nonstop for 60+ years, which is a reasonable thing to assume will not happen.

If case (b) is true, then the article needs a bit more research into examples of systems that actually rely on datetime.

learc83• 13 years ago

I think it's more of they use datetime for logging events and no one has really tested the ECU to see what happens to it when datetime overflows. I think it's very unlikely it would actually affect ABS.

Now that I think of it, I don't believe ECUs have internal batteries, so every time your battery dies the clock would be reset anyway.

aidenn0• 13 years ago

I think you're right; there are some systems that maintain time even when the car is off, but most of those will reset when you replace the starter battery.

derekp7• 13 years ago

Seen the same thing back with Y2K -- all kinds of scare mongering using countless embedded systems as examples -- but not one of those examples has an interface where you can set the current date/time. As long as it isn't blinking "12:00" (or more precisely "Jan 1, 1970 00:00 UTC") when you first turn it on, you don't have to worry about it.

Sure you have to set the time on your microwave, but none of the ones I've had displayed a calendar date.

jrabone3• 13 years ago

True. There are also some ingenious "solutions" out there - like my DECT phone for example. The interface takes time and date (with NO year field) in one menu, and day-of-week in a different menu on the base station... (if it's got a look-up table somewhere and is calculating epoch-second timestamps from this I will ritually burn it.)

rachelbythebay• 13 years ago

There was a cell phone which couldn't focus its camera for two weeks at a time, then could again, and so on. It had something to do with the time stamps of samples it read from its sensor and a sign extension gone wrong.

I never imagined the internal clock could affect camera focus, but it did.

lambersley• 13 years ago

When Y2K happened, I was just entering the workforce. I missed the opportunity to capitalize on the madness. This time, this time I will profit

404error2• 13 years ago

No need to worry about this. John Titor will fix this problem.

http://en.wikipedia.org/wiki/John_Titor

johansch2• 13 years ago

Three options:

1) Someone gone insane from too much exposure to IBM mainframes (seems quite likely)

2) A great performance artist - making us all think

3) A real time traveller

404error2• 13 years ago

According to Titor though what ever he did in our time would not directly affect his time. He traveled through time to a parallel universe(our universe) where things are pretty similar to his time with some differences.

According to him the farther back or forward in time he goes the more things change.

So, with that said, we might still be screwed. But maybe we can find an IBM 5100 and solve this problem.

victor_foster• 13 years ago

Have to say, this is the first thing I thought of as well.

mindcrime• 13 years ago

Or this guy:

http://timetraveler.ytmnd.com/

Unless he is John Titor!

IvyMike• 13 years ago

Has anyone made a virtual IBM 5100 and posted the image to Pirate Bay yet?

It sure (would have saved / will save) him a ton of trouble.

guard-of-terra• 13 years ago

Java won't be affected because it sees timestamp as a 64-bit signed number of milliseconds since epoch.

It's precise enough for logging now and also timeproof.

This is fortunate because there are huge legacy java codebases. However, problems may still arise where java talks to other things (databases, input/output).

smackfu• 13 years ago

There's also another Year 20XX problem lurking out there.

A lot of mainframe code that was fixed for Year 2000 had two-digit years in the data, that was converted to a four-digit year by adding 1900. The "fix" for a lot of that was to say if it was less than 70 (or whatever cutoff handled all the dates for the application), add 2000, otherwise add 1900. 72 => 1972, 00 => 2000, 13 => 2013. This fails in 2070, with 2070 being reported as 1970 again.

That same software is untouched 13 years later... I don't have hopes for it being updated soon.

colkassad• 13 years ago

Just curious, was anyone talking about Y2K back in 1975?

pserwylo• 13 years ago

"REPENT FOR THE END OF THE UNIX EPOCH IS NIGH" [0]

... was a very entertaining and interesting talk from linux.conf.au 2013. The first ten or so minutes is amazing theater and quite hilarious (at least it was when I saw it live), and the remaining talk is also very informative.

It deals with quite a clever way to re-use the existing timezone databases that are designed to work with 32bit dates, such that they are usable with 64bit dates. This is important, because it is already an extremely difficult task to keep the original 32bit timezone databases up to date (what with all of the political decisions to change daylight savings - at a few months notice).

The talk is from the perspective of a perl developer, but the discussion is for anyone who is interested in solving the Year 2038 Problem in their language of choice.

[0] http://www.youtube.com/watch?v=eQFZ_MPTVpc

or 91mb mp4 download:

http://mirror.linux.org.au/linux.conf.au/2013/mp4/REPENT_FOR...

devinfoley• 13 years ago

I ran into this issue recently.

You can't create an authenticated S3 URL without an expiration date, and it doesn't accept an expiration date after 2038.

human_error• 13 years ago

This has been fixed couple of years ago in mortgage systems.

sopooneo• 13 years ago

The Y2K issue was at least explainable to non-techs. Storing two digits is ambiguous. Simple enough. This one, though, no one is going to understand.

jlove• 13 years ago

This finally made me get around to posting my 2038 countdown clock.

http://diskclock.com/2013/05/unix-disk/

Year 2038 problem

Related Stories