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.
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.
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?
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.
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.
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.
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.
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.
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.
"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)."
"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.
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.
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.
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 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.
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.
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.
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.
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)
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'.
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.
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.
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.
"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.
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.
> 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.
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.
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.
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?
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.
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...
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.
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).
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:
On the future side, things have changed since I last looked. Example bonds with the latest dates I can find are: