11 ms·

Year 2038 problem

194 points by areski 13y ago

cleaver 13y 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 13y 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 13y ago
    I wouldn't worry too much. Soon we'll have .horse and .melbourne, all our TLD problems will be behind us.
    - cleaver 13y ago
      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.
    - wcfields 13y ago
      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.
- astrodust 13y 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.
api 13y 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 13y 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 13y ago
    So there's the rub. It's all the integration/glue code that's the problem. The dark matter of the programming world.
- 0x0 13y 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 13y 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.
  - angersock 13y ago
    When to pull the trigger... sometime around new year's day on 1970?
lucb1e 13y 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 13y 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 13y 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 13y ago
  Or define your 64bit timestamp to be in nanoseconds, in which case it will only last till year 2555.
- masklinn 13y 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 13y 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 13y ago
  640kB ought to be enough for everyone, right.
Ovid 13y ago
Actually, a friend of mine has written a fix for it (https://github.com/schwern/y2038 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.
- 0x0 13y ago
  This won't help you if you need to interface with existing files or protocols...
  - Ovid 13y 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).
    - apaprocki 13y ago
      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.
  - btilly 13y ago
    Change all unsigned ints that store time to signed. In another 68 years or so, change them all back to unsigned. :-)
    - GhotiFish 13y ago
codeulike 13y ago
I hope humans are still around to deal with the eventual Y10K problem.
ck2 13y 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.
- Ovid 13y 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".
  - ck2 13y 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.
normalocity 13y 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 13y 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 13y ago
You can use `libfaketime` to test your software: * https://github.com/wolfcw/libfaketime https://github.com/wolfcw/libfaketime Shameless plug: my project `fluxcapacitor` may also be useful for testing: * https://github.com/majek/fluxcapacitor https://github.com/majek/fluxcapacitor
- Aissen 13y ago
  fluxcapacitor looks like 'macfly': https://github.com/haypo/macfly https://github.com/haypo/macfly
- ccozan 13y 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.
apaprocki 13y 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/n3344.pdf 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
- deleted 13y ago
  [deleted]
- kevindication 13y 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.
  - apaprocki 13y 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.
- HorizonXP 13y 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?
jrabone 13y ago
You leave that bug alone, that's my retirement policy that is.
- mkopinsky 13y ago
  Your "pull me out of retirement to fix mission critical bugs" policy, rather.
  - angersock 13y ago
    That's funny, where I'm from the policy is called "jQuery".
    - jrabone 13y ago
      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!
Graham24 13y 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.
- johansch 13y ago
  You might find this thing I found on the web just now amusing: http://forums.buffalotech.com/t5/Storage/CloudStor-Date-Time-02-07-2036-1-28am/td-p/63274 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)."
- glhaynes 13y 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 13y ago
  Were people actually expecting nuclear reactors to "blow up" because of a software problem? http://en.wikipedia.org/wiki/Passive_nuclear_safety http://en.wikipedia.org/wiki/Passive_nuclear_safety
elliottcarlson 13y 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 13y ago
This bug is my retirement fund :) Just like those COBOL guys back in 2000.
yoster 13y ago
Rerun of Y2K...
Eva_Peron 13y 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 13y 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.
- astrodust 13y 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 13y ago
    But the point is that the implementations can be fixed, one by one, without breaking the protocol.
pilif 13y 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 13y ago
  http://xkcd.com/607/ http://xkcd.com/607/
- Dylan16807 13y 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 13y ago
I was there when Y2k happened! Alas, nothing happened except I was suffering from a huge hangover the very next morning.
- mark-r 13y ago
  I ended up with a gas station receipt that said "1/1/100". That was the extent of it.
jtwigg 13y ago
watch out for the Year 292,277,026,596 problem
- astangl 13y 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 13y 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 13y ago
  Countdown Timer. Should underflow at the last second, of course.
ryanthejuggler 13y 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 13y 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 13y 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 13y 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.
  - jrabone 13y ago
lambersley 13y 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
404error 13y ago
No need to worry about this. John Titor will fix this problem. http://en.wikipedia.org/wiki/John_Titor http://en.wikipedia.org/wiki/John_Titor
- johansch 13y 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
  - 404error 13y 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 13y ago
  Have to say, this is the first thing I thought of as well.
- mindcrime 13y ago
  Or this guy: http://timetraveler.ytmnd.com/ http://timetraveler.ytmnd.com/ Unless he is John Titor!
- IvyMike 13y 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 13y 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 13y 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 13y ago
Just curious, was anyone talking about Y2K back in 1975?
pserwylo 13y 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 http://www.youtube.com/watch?v=eQFZ_MPTVpc or 91mb mp4 download: http://mirror.linux.org.au/linux.conf.au/2013/mp4/REPENT_FOR_THE_END_OF_THE_UNIX_EPOCH_IS_NIGH.mp4 http://mirror.linux.org.au/linux.conf.au/2013/mp4/REPENT_FOR...
devinfoley 13y 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 13y ago
This has been fixed couple of years ago in mortgage systems.
sopooneo 13y 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 13y ago
This finally made me get around to posting my 2038 countdown clock. http://diskclock.com/2013/05/unix-disk/ http://diskclock.com/2013/05/unix-disk/

Year 2038 problem

194 points by areski 13y 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 13y 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 13y ago
  I wouldn't worry too much. Soon we'll have .horse and .melbourne, all our TLD problems will be behind us.
  - cleaver 13y ago
    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.
  - wcfields 13y ago
    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.
astrodust 13y 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.

api 13y 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 13y 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 13y ago
  So there's the rub. It's all the integration/glue code that's the problem. The dark matter of the programming world.
0x0 13y 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 13y 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.
- angersock 13y ago
  When to pull the trigger... sometime around new year's day on 1970?

lucb1e 13y 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 13y 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 13y 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 13y ago
Or define your 64bit timestamp to be in nanoseconds, in which case it will only last till year 2555.
masklinn 13y 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 13y 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 13y ago
640kB ought to be enough for everyone, right.

Ovid 13y ago

Actually, a friend of mine has written a fix for it (https://github.com/schwern/y2038 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.

0x0 13y ago
This won't help you if you need to interface with existing files or protocols...
- Ovid 13y 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).
  - apaprocki 13y ago
    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.
- btilly 13y ago
  Change all unsigned ints that store time to signed. In another 68 years or so, change them all back to unsigned. :-)
  - GhotiFish 13y ago

codeulike 13y ago

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

ck2 13y 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.

Ovid 13y 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".
- ck2 13y 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.

normalocity 13y 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 13y 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 13y ago

You can use `libfaketime` to test your software: * https://github.com/wolfcw/libfaketime https://github.com/wolfcw/libfaketime Shameless plug: my project `fluxcapacitor` may also be useful for testing: * https://github.com/majek/fluxcapacitor https://github.com/majek/fluxcapacitor

Aissen 13y ago
fluxcapacitor looks like 'macfly': https://github.com/haypo/macfly https://github.com/haypo/macfly
ccozan 13y 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.

apaprocki 13y 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/n3344.pdf 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

deleted 13y ago
[deleted]
kevindication 13y 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.
- apaprocki 13y 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.
HorizonXP 13y 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?

jrabone 13y ago

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

mkopinsky 13y ago
Your "pull me out of retirement to fix mission critical bugs" policy, rather.
- angersock 13y ago
  That's funny, where I'm from the policy is called "jQuery".
  - jrabone 13y ago
    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!

Graham24 13y 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.

johansch 13y ago
You might find this thing I found on the web just now amusing: http://forums.buffalotech.com/t5/Storage/CloudStor-Date-Time-02-07-2036-1-28am/td-p/63274 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)."
glhaynes 13y 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 13y ago
Were people actually expecting nuclear reactors to "blow up" because of a software problem? http://en.wikipedia.org/wiki/Passive_nuclear_safety http://en.wikipedia.org/wiki/Passive_nuclear_safety

elliottcarlson 13y 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 13y ago

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

yoster 13y ago

Rerun of Y2K...

Eva_Peron 13y 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 13y 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.

astrodust 13y 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 13y ago
  But the point is that the implementations can be fixed, one by one, without breaking the protocol.

pilif 13y 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 13y ago
http://xkcd.com/607/ http://xkcd.com/607/
Dylan16807 13y 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 13y ago

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

mark-r 13y ago
I ended up with a gas station receipt that said "1/1/100". That was the extent of it.

jtwigg 13y ago

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

astangl 13y 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 13y 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 13y ago
Countdown Timer. Should underflow at the last second, of course.

ryanthejuggler 13y 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 13y 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 13y 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 13y 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.
- jrabone 13y ago

lambersley 13y 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

404error 13y ago

No need to worry about this. John Titor will fix this problem. http://en.wikipedia.org/wiki/John_Titor http://en.wikipedia.org/wiki/John_Titor

johansch 13y 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
- 404error 13y 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 13y ago
Have to say, this is the first thing I thought of as well.
mindcrime 13y ago
Or this guy: http://timetraveler.ytmnd.com/ http://timetraveler.ytmnd.com/ Unless he is John Titor!
IvyMike 13y 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 13y 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 13y 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 13y ago

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

pserwylo 13y 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 http://www.youtube.com/watch?v=eQFZ_MPTVpc or 91mb mp4 download: http://mirror.linux.org.au/linux.conf.au/2013/mp4/REPENT_FOR_THE_END_OF_THE_UNIX_EPOCH_IS_NIGH.mp4 http://mirror.linux.org.au/linux.conf.au/2013/mp4/REPENT_FOR...

devinfoley 13y 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 13y ago

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

sopooneo 13y 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 13y ago

This finally made me get around to posting my 2038 countdown clock. http://diskclock.com/2013/05/unix-disk/ http://diskclock.com/2013/05/unix-disk/