Year 2038 problem | Hacker News Reader

Year 2038 problem

en.wikipedia.org

194 pointsareski108 comments

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

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.

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.

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?

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.

What kind of yields would that be though? I would expect that I would get my original investment returned to me many times over during my lifetime. After that, it wouldn't matter to me, but rather to my descendants.

Coupon on the HSBC bond is 7.125%.

Fascinating, where do you find these bonds and/or info on them? Do you work for a financial institution that have internal proprietary access to such information, or is this publicly searchable?

All that info is on Bloomberg.

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.

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

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.

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

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

Well, tzdata zones usually either always have per-year entries (such as Morocco) or entries that describe "from now on". So the logic in the code would be valid for places like the US that very infrequently change DST rules -- it would only break if the US changed their DST rules after 2037. It appears anglocentric, though. If a user in Morocco used this on their system, it would undoubtedly lead to errors because Ramadan falls on different days every year and DST is not observed during Ramadan. Things would start to fail in subtle ways because DST might not be calculated correctly for a few days here or there every year depending on what timezone it is used with.

Change all unsigned ints that store time to signed.

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

:-)

While I agree this works, It's also a bit unnerving to me that 68 years later we're still using a protocol that's using a representation of time that rolls over every 126 years.

Oops, got it backwards. Right now they are signed. Change them to unsigned. Then back and forth.

Of course if you miss any...

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.

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

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.

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

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

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

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.

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.

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.

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

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.

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

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

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.

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.

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

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.

It's not the ALTER that's expensive, it's the people who have to figure out that the ALTER has to be run, set up testing environments, run test cases, verify them, run the actual update in production, etc. (Or: possibly miss it and thus end up with bad data or crashes in production.)

I'd think the number of cases in which it's a worthwhile tradeoff for new development to save 4 bytes times even tens of millions of rows (each million costs you 4 MB, the size of a song) is vanishingly small today.

If you have to use time in multiple indexes, you would use significantly more than 4MB in a 10 million row table with 64bit vs 32bit integers.

So what? You're describing a bug, not an optimization.

If you only have 5000 products, you might as well use a 16 bit field. If you only have 10 million messages, you might as well use a 32 bit field. If you only deal with times before 2038, you might as well use a 32 bit field. It's a bug if the code isn't flexible, but there is no reason to waste extra space in the database to store 0s.

Just like there was never any point in keeping the first two digits of a year? Until Y2K approached and tons of code was still in production that hadn't ever been expected to live that long. It cost companies a lot of money. Why make the same mistake again?

I'm not saying optimizations like that are never worth it, but as a general rule the case would have to be made extremely well for me to ever sign off on it. And I bet in the huge majority of cases, the time cost of making that case would exceed the extra storage cost for using "unoptimized" data structures.

I can't find it at the moment but I remember reading a study showing that even with the cost of fixing Y2K issues it was still an economically sound decision to use two digit years given the historical cost of storage. In other words it was cheaper to fix the problem in 1999 than it would have been to buy enough mainframe storage in 1979 to store the extra two digits.

Hah! Yeah, I could definitely see that being true. It was hasty of me to refer to that as "a mistake": as you say, that was a world in which every byte was several orders of magnitude more expensive.

To save a similar amount of money on storage today of course it'd probably have to be tens or hundreds of kilobytes wasted per record. That kind of an optimization would very often still be worth looking into and optimizing for.

We're talking about a database here, not the code that processes a few records at a time. That code should be future proofed. But while the database design should be future proof, the exact settings don't have to be. Keep things properly isolated and nobody will ever know how many bits the database takes to store a value, and you can change it behind their backs with a single ALTER.

you can change it behind their backs with a single ALTER

If you're still there in 2038. And remember to do it.

And someone hasn't written code based and tested on the 32bit date that then starts blowing (or even worse subtly making mistakes) up when you switch to 64bits...

That code is going to work/break the same with or without the database being expanded. Only truly ridiculous code would depend on the fact that inserting a date in 2040 causes the database to reject that transaction. Anything else in the code involving dates should have unit tests but is entirely independent of the database.

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.

I just kept recompiling it until it tasted right.

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.

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.

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.

So there's the rub.

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

The dark matter of the programming world.

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

There will be a LOT of patching.

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.

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

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)

http://xkcd.com/607/

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

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

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

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

Every generation of coders has its retirement policy. Just think where we'd be if every large company was agile, responsive, and kept their code up to date. We cannot afford to let the big banks, governments and healthcare companies keep up!

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.

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.

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

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

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

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

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.

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

Or this guy:

http://timetraveler.ytmnd.com/

Unless he is John Titor!

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.

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.

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.

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

I'll be snapping up 2038.horse for sure. Once all our computer controlled hybrid vehicles stop functioning, I predict a booming market for horses.

I like to think there's someone in NBC's Standards and Practices department who has a Google news alert set for when the ".fart" domain is announced.

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.

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

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.

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.

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

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

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

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.

640kB ought to be enough for everyone, right.

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?

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.

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.

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

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.

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.

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

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

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.

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

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

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.

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

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.

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

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

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.

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.

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

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

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

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

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

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

Rerun of Y2K...

Reply on news.ycombinator.com