Forgot your password?
typodupeerror
Bug Programming Unix

You've Got 25 Years Until UNIX Time Overflows 492

Posted by timothy
from the start-packing dept.
CowboyRobot writes "In 25 years, an odd thing will happen to some of the no doubt very large number of computing devices in our world: an old, well-known and well-understood bug will cause their calculation of time to fail. The problem springs from the use of a 32-bit signed integer to store a time value, as a number of seconds since 00:00:00 UTC on Thursday, 1 January 1970, a practice begun in early UNIX systems with the standard C library data structure time_t. On January 19, 2038, at 03:14:08 UTC that integer will overflow. It's not difficult to come up with cases where the problem could be real today. Imagine a mortgage amortization program projecting payments out into the future for a 30-year mortgage. Or imagine those phony programs politicians use to project government expenditures, or demographic software, and so on. It's too early for panic, but those of us in the early parts of their careers will be the ones who have to deal with the problem."
This discussion has been archived. No new comments can be posted.

You've Got 25 Years Until UNIX Time Overflows

Comments Filter:
  • those phony programs politicians use to project government expenditures

    The programs are real, even if the math may be phony.

    • by Anonymous Coward on Tuesday January 22, 2013 @11:37AM (#42657267)

      History shows us that it's not biased in the slightest to assume that politicians will lie, cheat, and steal their way to riches. Giving them the benefit of the doubt is like Charlie Brown giving that field goal one more shot because maybe, just maybe, Lucy won't pull the ball this time.

      • Most Insightful Post Ever!

      • Re: (Score:2, Funny)

        by Anonymous Coward

        History shows us that

        Blah blah blah. The parent was not giving anyone the benefit of the doubt. And just FYI the whole football thing was an analogy for sex.

        As for the article, I'll sum it up for everyone: "Y2K is coming to get youuuuuuuuuuuuuuuuuu!!!! Hide the children!"

        • by Anonymous Coward on Tuesday January 22, 2013 @12:36PM (#42657913)

          ...And just FYI the whole football thing was an analogy for sex....

          And anyway, Peter Griffin took care of that football thing once and for all.

        • by dbIII (701233)
          Y2K did come and get me as late as 2008, when an idiot at Macrovision changed a copy protection program to use two digit years again, and I had software with permanent licences using data zero to mark that it was permanent. Suddenly it stopped working, stating that our licences expired in 2000 and there was no way back, since the new licence also wouldn't work with the older version of the Macrovision flexnet shit so for two weeks nobody could run the $10k per seat real software. Macrovision would not dea
      • by i_ate_god (899684) on Tuesday January 22, 2013 @12:44PM (#42658027) Homepage

        You would think that if all politicians cared about was their own greed, they'd be far better off than they are now no?

      • by dkleinsc (563838) on Tuesday January 22, 2013 @01:47PM (#42658793) Homepage

        History shows us that it's not biased in the slightest to assume that politicians will lie, cheat, and steal their way to riches.

        What is biased is to assume that the non-elected civil servants who actually do the math will not attempt to do their jobs to the best of their ability. For example, the staff at the Congressional Budget Office who actually do the math do not directly report to any politician. Similarly, the civil service laws exist specifically to prevent someone from, say, being fired by NOAA for coming up with the "wrong" climate data, or fired from the SSA for coming up with the "wrong" Social Security budget projections.

        So you're right to assume that politicians lie, cheat, and steal. But that doesn't mean that a GS-11 actuary working in the bowels of a government agency is lying in his reports.

        • by ByOhTek (1181381)

          Have you worked in "the trenches" in those sectors before.

          (1) You may not be able to be fired for those reasons, but most employers can easily find other reasons to fire an employee. So there's still that fear. It doesn't happen /just/ in Corporate America.
          (2) Even if you aren't directly/indirectly reporting to a political figure, they still pull enough strings to make you worry, and they can still exert influence outside of the chain of command.

          It's not a cut and dry situation. There are buffers, but none

    • by tlhIngan (30335) <.slashdot. .at. .worf.net.> on Tuesday January 22, 2013 @12:21PM (#42657781)

      Actually, banks, and such already ran into Y2K problems in the 70s when long term loans starting overflowing them. For them the Y2K scenario had many years to be fixed slowly (mostly a continuous updating thing - as things broke, they fixed it) so there was no big rush for them as they were experienced in such issues.

      If there are any 2038 issues, the banks have already been ahead of the curve and seeing them in 2008. Hell, a good conspiracy theory....

      time_t has also been 64 bit for a number of years now (you don't need a 64-bit system to deal with 64-bit numbers - it's just dealing with them is a lot slower as the compiler emits library calls to perform the arithmetic). So it's not a real problem even on embedded systems (ARM only added 64-bit support in the ARMv8 instruction set - and only in the high-end A (applications) profile processors - the lower end R (real-time) and M (microcontroller) profiles are still ARMv7 only).

      However, even those compiled with 64-bit time_t aren't necessarily safe - you'd probably find most of them assume it's still a 32-bit quantity and end up storing it as such - ignoring the compiler warnings or casting to get rid of them. So even programs of today with 64-bit time_t's won't necessarily make it past 2038 either.

      And if stuff like that is done, recompiling does diddly - the bug will still strike despite a 64-bit everything. Hell, someone may have decided during the conversio nto increase the timestamp size from 32 to 64 bit, but didn't realize someone squashed it down to 32-bit upstream.

      • by interval1066 (668936) on Tuesday January 22, 2013 @01:05PM (#42658279) Homepage Journal

        you don't need a 64-bit system to deal with 64-bit numbers - it's just dealing with them is a lot slower as the compiler emits library calls to perform the arithmetic...

        A lot slower? Nah. Negligble, at best. It'll be fine.

      • by Anonymous Coward on Tuesday January 22, 2013 @01:49PM (#42658821)

        For them the Y2K scenario had many years to be fixed slowly (mostly a continuous updating thing - as things broke, they fixed it) so there was no big rush for them

        There's a motorcycle shop in my town where all the receipts are dated "1913". And printed with tractor feed dot-matrix.

        So not everybody's in a big hurry.

      • by Darinbob (1142669) on Tuesday January 22, 2013 @03:04PM (#42659745)

        I've seen some relatively new systems using a 32-bit time, even some using the same API as Unix. It's relatively common in embedded systems. Many of them just go ahead and use signed 32-bit as there's no need to have internal times be compatible with external systems.

        Ultimately I think the problem arises because of overusing time_t. Originally this was something you used to attach a time to a file in a file system, or a time in a log entry, etc. A time system on a file system with a limited range is not a problem. That media is not going to be active 40 years later. The file may last longer but in such cases presumably it's copied to new media with a different method of storing times. So not a problem for file systems to do this. The problem however is that this time system was expanded to be used for more general purpose times. And over time it's practically a de-facto standard to stick with time_t and its 1/1/1970 base date. People don't think about converting from system time into an external time when exporting data, they just assume time_t is valid everywhere. Programmers just use whatever time system they find in the system's libraries without worrying about whether it is an appropriate use or not.

        Many application areas already have to avoid using time_t anyway and are used to converting between one time system to another. Astronomy, geneology, medical records, historical data, etc.

      • Actually, banks, and such already ran into Y2K problems in the 70s when long term loans starting overflowing them. For them the Y2K scenario had many years to be fixed slowly (mostly a continuous updating thing - as things broke, they fixed it) so there was no big rush for them as they were experienced in such issues.

        It's times like this when I really, really miss VMS.

      • 64-bit time ends on 15:30:08 on Sunday, 4 December 292,277,026,596

        you think the programmers in that year will be happy with the mess you left them?

        not really planning ahead now are you geniuses?

        dear coders of year 292 billion: i'm sorry, we failed you

  • Not NetBSD (Score:5, Informative)

    by Nimey (114278) on Tuesday January 22, 2013 @11:04AM (#42656775) Homepage Journal

    NetBSD has switched to a 64-bit time_t.

    • Re:Not NetBSD (Score:4, Insightful)

      by Beezlebub33 (1220368) on Tuesday January 22, 2013 @11:07AM (#42656811)
      64-bit is taking over already everywhere. In 10-15 years, you will have a hard time finding a 32-bit computer. (Actually, you might have a hard time finding a 'computer' at some point but that's a whole other issue). With the change to 64 bits, more and more OS's will operate on 64-bit time, and this will not be an issue.
      • by JcMorin (930466) on Tuesday January 22, 2013 @11:12AM (#42656879)
        Having a 64-bit will not solve this at all. The problem lie in the software, if a 32-bit time structure as been used, no matter on what computer it's running it will be emulated as a 32-bit application with only 32-bit of memory for time allocation. It will bust, I can see a whole bunch of old program still running because "it work" and company, especially big companies, do not re-write the software in 64 bit.
        • by h4rr4r (612664) on Tuesday January 22, 2013 @11:17AM (#42656963)

          64bit time will solve it for anything that uses time from the system directly. Meaning all those perl and bash scripts that run so much stuff no one thinks about, from billing to transferring data between companies to scheduling your next vacation are going to be fine.

          What will not be fine is crusty old compiled code that was 32bit. Hopefully they are just a recompile away from being fixed. Sadly that is likely not to be the case as generally corporations do not have that kind of foresight.

          • by locofungus (179280) on Tuesday January 22, 2013 @11:33AM (#42657215)

            Compiling away isn't always that simple.

            You'd be amazed how many people code depending on the fact that sizeof(long) == sizeof(int) == sizeof(void*) == sizeof(time_t) == 4 even when they don't need to and structures are often mapped directly onto binary data, either from disk or network.

            I don't actually imagine that 2038 will be much of a problem - most of the issues that will be triggered by the above assumptions will occur between now and then and will be fixed as they occur.

            Then 2038 will loom and there will be a big drive to fix everything (else), the magic time will occur and there will be little more than a whimper. Then everyone will complain about the hype about a non-existent problem.

            I am quite looking forward to having the option of some lucrative consulting income in my early retirement should I decide I need it. :-)

            Tim.

            • by HaZardman27 (1521119) on Tuesday January 22, 2013 @11:47AM (#42657411)

              I am quite looking forward to having the option of some lucrative consulting income in my early retirement should I decide I need it. :-)

              Then my goal is to thwart your retirement plan. I will contract a low-wage programmer from a yet-to-be-determined developing country to write a piece of software that corrects the issue in any source code and recompiles it for you. I'll sell licenses for $1kUSD a pop, which by 2038 will only be enough to cover the cost of a McDonalds Synthetic Cheeseburger Paste from the Value Menu.

        • by Hatta (162192)

          If you have a 64 bit PC and OS, it should be little more than a recompile. This is why it's important to have the source.

          • by stoborrobots (577882) on Tuesday January 22, 2013 @12:37PM (#42657923)

            If you have a 64 bit PC and OS, it should be little more than a recompile.

            A number of comments have claimed this: recompile with 64-bit time_t and the problem goes away. Unfortunately, for many apps it's not quite as simple as that.

            Certainly, for those apps which only deal with time information internally, and in a transient fashion, this will be sufficient to eliminate the problem.

            However any program which persists UNIX timestamps in files, or sends UNIX timestamps as part of a networking protocol, or basically anything which sends the data structure outside the application is still going to require work on how to handle the migration.

            What happens if your app is required to talk on the network? If there are few enough machines involved, then sure, you can upgrade all of them at once, but if it's a large or distributed operation, there needs to be a transition plan. How will older clients and newer clients interoperate?

            If data is saved, how will the recompiled application interpret old files? Does it need a way to distinguish them? Can old data be automatically converted? Are there cases where old data may be compromised? (e.g. those 30 year mortgages probably have the wrong end-date stored...) How will we handle those cases?

            What about situations where time information is used to prime other calculations - is it okay to affect those other calculations? Serial numbers, PRNGs, UUID generation, etc - the situation has to be assessed. Many cases might be fine, but you can't make a blanket statement for all cases, so each calculation must be vetted.

            In the end, the result is that there is work to do. Much of it will be easy to fix, but the assessment still needs to be done.

            • If you have a 64 bit PC and OS, it should be little more than a recompile.

              A number of comments have claimed this: recompile with 64-bit time_t and the problem goes away. Unfortunately, for many apps it's not quite as simple as that.

              Certainly, for those apps which only deal with time information internally, and in a transient fashion, this will be sufficient to eliminate the problem.

              However any program which persists UNIX timestamps in files, or sends UNIX timestamps as part of a networking protocol...

              Oh, IPv6 should take care of that.

      • embedded (Score:5, Informative)

        by Anonymous Coward on Tuesday January 22, 2013 @11:37AM (#42657283)

        64-bit is taking over already everywhere. In 10-15 years, you will have a hard time finding a 32-bit computer.

        The embedded world will still have a lot of 32-bit (as well as 16- and 8-bit) stuff for years to come.

        That's where the big problem will be: not with the systems on your desk (or on your lap, or in your pocket), but rather with the hundreds of little CPUs that you don't see (and you may, or may not, be aware of).

      • Re:Not NetBSD (Score:5, Informative)

        by petermgreen (876956) <plugwashNO@SPAMp10link.net> on Tuesday January 22, 2013 @11:40AM (#42657319) Homepage

        The problem is not so much the OS, as you say most systems will be running 64-bit operating systems and even 32-bit operating systems will likely find a soloution (like was done for large file support). The problem is the applications which have the assumption of 32-bit unix time built in.

        You might say "just recompile for 64-bit" but that assumes that

        1: you have the source
        2: the source is not full of assumptions that make rebuilding for 64-bit impractical
        3: the source actually stores the time in variables of type time_t or long and not variables of type int or type int32_t.
        4: the data files the program stores on-disk do not include timestamps in unix format in fixed size fields.

        For what proportion of applications do you belive all four of those assmptions will hold.

    • by gweihir (88907)

      At least 64 bit Linux has too. The only 32 bit installation I have (on a Raspberry Pi) has not.

      • by WilyCoder (736280)

        Don't forget the Rpi doesn't even have a real time clock...

        • by gweihir (88907)

          Yes, I know. A limitation found on quite a few other embedded systems. My intuition is that on something without real-time clock, this issue cannot be important.

  • That's OK (Score:5, Funny)

    by Big Hairy Ian (1155547) on Tuesday January 22, 2013 @11:06AM (#42656793)
    The IOS reminder service will fail for the first week in January atleast once before then :)
  • by killfixx (148785) * on Tuesday January 22, 2013 @11:06AM (#42656807) Journal

    Standing before the steam roller....

    "Stoooooooooooooooooooooooooooooooooooooooooooop".... .... "Stooooooooooooooooooooooooooooooooop"....

    I understand, we need time to correct the issue, but...c'mon?!

    Slow news day?

  • Unsigned! (Score:4, Interesting)

    by aglider (2435074) on Tuesday January 22, 2013 @11:07AM (#42656831) Homepage
    32bit unsigned, not signed! What'd be the negative timestamps for? Ages before 1970?
    • "32bit unsigned, not signed!"
      no you heard correct.

      "What'd be the negative timestamps for? Ages before 1970?"

      but you managed to guess this correctly.
      • by vlm (69642)

        Also a timestamp, in addition to being referenced to 0 = somesuch date, also can be used with offsets. So add a signed integer "-60" to the timestamp signed integer to get a signed integer representing about a minute ago. Since you'll be spending a lot of time adding signed ints to a timestamp, you may as well make the thing a signed int, rather than having to screw up and debug a zillion crappy bug filled homemade implementations of "uint + int = uint". Most of the bugs are dealing with extreme values a

    • Do the math. If they used a 32-bit unsigned integer, the problem wouldn't happen until the year 2106.

      • We made this decision for our C library on our embedded 65816 processor used in industrial controllers. We had no reason to represent times before the controller was installed, so losing the sign wasn't an issue. But we thought that 2038 was within the possible useful life span of the controller. 2106, not so much.

        I realize that many people thought that about hardware produced for the century turnover as well, so everything about the time range is internally documented well, but we didn't have any justifica

    • Ages before 1970?

      Some applications need to represent times before 1970 (for example dates of birth*)
      Some applications need to work with time differences.
      Some applications use negative numbers to represent errors.

      Unsigned 32-bit unix time values may be useful as a quick fix in some specific scenarios where a field in a data structure is fixed size, where it is accepted that the code processing that field will need to be updated and where it is known that dates before 1970 will not be needed but attempts to use them as a gene

  • by boristdog (133725) on Tuesday January 22, 2013 @11:08AM (#42656845)

    I put in my time working on the Y2K fix. I'll be retired in 5 years, so let the kids of today fix this one. Hell, they need jobs.

    • by slim (1652)

      Yep. We knew Y2K was coming. We tested stuff. We fixed stuff. We got double-time for being on-call instead of partying like it's 1999. And because of all of that, it went smoothly.

      The same thing will happen here. All it needs is for management to put people on the tasks.

  • by bill_mcgonigle (4333) * on Tuesday January 22, 2013 @11:09AM (#42656855) Homepage Journal

    Was this a USENET post from '94? Mortgage systems using 32-bit time_t (if there ever were any) failed 5 years ago for 30-year mortgages. We did not hear an earth-shattering kaboom.

    • by Anonymous Coward on Tuesday January 22, 2013 @11:19AM (#42657001)

      Actually we did, but it had nothing to do with integer overflow.

    • by Exitar (809068)

      The global crysis!
      I blame UNIX for that!

    • by Thud457 (234763) on Tuesday January 22, 2013 @11:25AM (#42657081) Homepage Journal

      Mortgage systems using 32-bit time_t (if there ever were any) failed 5 years ago for 30-year mortgages.

      Oh, that was what that was. Oh crap.
      And here all along I've been blaming greedy mortgage brokers for suckering people into mortgages they couldn't afford and a insanely inflated real estate market.

    • by plover (150551)

      Five years ago there was an economy-shattering real estate crash due to shady sub-prime mortgages. Coincidence or coverup?

      Just kidding; of course it was a coincidence. But if you throw out statements like this, the conspiracy theorists come out of the woodwork. You could even say the moon landings were faked because the time on the computers of the day was kept in an 8-bit register, which rolled over during the Apollo 13 mission!

    • Was this a USENET post from '94? Mortgage systems using 32-bit time_t (if there ever were any) failed 5 years ago for 30-year mortgages. We did not hear an earth-shattering kaboom.

      Maybe that's because accountant types seem to think that the only valid numerical inaccuracies are those manifested in base 10, so they tend to use their own weird decimal number types for financial calculations.

  • This could be worse than Y2K!

    • This could be worse than Y2K!

      . . . and more lucrative, for retired C hackers who want to earn a few bucks . . .

      The COBOL boys had their turn with Y2K. Next up, are the C-bies.

  • Noooooooo! (Score:5, Funny)

    by lxs (131946) on Tuesday January 22, 2013 @11:17AM (#42656971)

    My uptime!

  • After all, we handily averted Y2K with decades to spare, and the internet has been migrated to IPv6 for the past ten years. :-P

  • The Wikipedia article [wikipedia.org] is much better than the Byte article. (Do people still read Byte? I don't remember seeing it since the 80's.)

    One thing that seems a little different from Y2K is that this bug seems to be prevalent in a lot of embedded systems. To me that seems harder to test than a desktop system. On a desktop system, you can just set the time to Dec. 31, 2037, let it roll over, and test as much stuff as possible to see if it broke. You can't do that with a car or an airliner.

    • by ledow (319597)

      Why can't you do that with an airliner? Maybe a car, but a car that's still running in 25 years is quite an achievement anyway.

      On an airliner? Just basic operational procedure would mean that updates for fixes are common (physical or software) to fix ANY potential problem after YEARS of testing on identical systems deployed in test labs.

      There's almost certainly a copy of a Boeing's internals at Boeing where they've done exactly this (e.g. test Y2K rollover to make sure it doesn't affect flightplan or auto

      • by LDAPMAN (930041)

        I've actually seen some situations close to your example. Imagine 286 desktop machines running Netware 2.X for SAA. It was at a hospital and the only guy that knew anything about them had been dead for almost 6 years. Finally enough of them failed to impact connectivity to the mainframe.

      • by vlm (69642)

        They're probably talking about endless dependency stream style bugs.

        For example. Say your shitty GPS rx curls up and dies with the 32 bit roll over. So it either stops sending fixes to the moving map or the moving map decides not to accept post-32-bit timestamps as part of the NMEA stream. Either way the position becomes static so the calculate airspeed drops to zero. Normally it would cross check against the two tubes, but those are clogged by ice today. So the autopilot shoves the stick far over beca

    • by Annirak (181684)

      (Do people still read Byte? I don't remember seeing it since the 80's.)

      Only in strings. We migrated to Words in the late '80s, then DWords in the '90s.

    • given that most new UNIX systems are now 64 bit to include new ARM machines, I don't see a scenario in 25 years where we will be using anything that requires the date to work.

      will most embedded systems need the date to work as an absolute, ot just need to count seconds? Why does an industrial robot care if its 2038 or 1901?
  • >> those phony programs politicians use to project government expenditures

    That's Excel in most cases, I bet. As long as spreadsheets can handle up to 50 rows and numbers up to 3000 I suspect all will be as it is today.

  • by Dyinobal (1427207) on Tuesday January 22, 2013 @11:19AM (#42656993)
    Time overflowing sounds like a good plot, instead of the usual time repeating, or other cliche time related plots. I'm just curious what the effects of a time overflow would be. *ponders* Maybe a break down in causality?
  • So it will be someone else's problem.

  • by ledow (319597)

    "Imagine a mortgage amortization program projecting payments out into the future for a 30-year mortgage."

    Well, that's a not-unreasonable example that almost certainly exists already, and seeing as we're only 25 years away - seems like the banks didn't really have any problems with that - at least, none they've advertised.

    So the real question is: How big a problem is it really? Application software can trundle off and do what it likes and ignore the clocks it knows are wrong, and 64-bit time systems like a

    • by gweihir (88907)

      I expect that financial calculations are using 64 bit or 128 bit integers, long-numbers or at the very least (may be illegal in some countries) double. The last still gives 56 bit integer precision when misused as an integer.

  • Cowboy Robot is yet another example of someone trying to use "facts" to create alarm, raise money, and achieve world government. If there were really a time problem in UNIX, and I don't believe it for a moment, it's not necessarily caused by human activity. I prefer sunspots. Yeah. Sunspots.

  • Rebaseline the count from say 2000; if it's good enough for the Pope to do it's good enough form me. And then we'd have Old Unix and GNU Unix
  • http://slashdot.org/comments.pl?sid=3356429&cid=42468505 [slashdot.org]

    But thanks for pointing it out again. Don't forget to stock up on Spam and Treet.

  • There -- it's fixed.
  • Shhhhh!! (Score:4, Interesting)

    by hawguy (1600213) on Tuesday January 22, 2013 @11:38AM (#42657293)

    Stop warning people! The Unix 32 bit Epoch cleanup is my retirement plan! I'll make a killing fixing legacy software when the kids out of school only know how to point and click through their GUI IDE's and don't know the difference between a short, an int, a long, and a long long... and time_t is completely foreign to them.

  • After having the time overflow on a previous offering, DEC made sure this wouldn't occur anytime soon in VMS. Quoting from the Wikipedia article on VMS, "The 100 nanosecond granularity implemented within OpenVMS and the 63-bit absolute time representation (the sign bit indicates absolute time when clear and relative time when set) should allow OpenVMS trouble-free time computations up to 31-JUL-31086 02:48:05.47. At this instant, all clocks and time-keeping operations in OpenVMS will suddenly fail, since
  • Unlike all the "big problems" in the world today, this one is real! I don't care about Kate having a baby or prince Harry smoked pot with Justin Beaver well Kim Celebrities is having an affair. This is actually a very real and important issue, yet how many people outside of the "nerd" community even know it exists. When the puck drops and Unix time overflows, I can promise you that all of a sudden what Kate's child is going to wear to her wedding is all of a sudden the least important headline in the papers
  • by hduff (570443) <hoytduff@@@gmail...com> on Tuesday January 22, 2013 @12:20PM (#42657761) Homepage Journal

    Not a problem since we'll all be running Windows 11 by then.

  • by craigminah (1885846) on Tuesday January 22, 2013 @12:58PM (#42658187)
    Future generations may think we intentionally used these values (e.g. start date and 32-bit signed integer) because we somehow know/predict the Earth will end on this date...

"Turn on, tune up, rock out." -- Billy Gibbons

Working...