back to article Linux clockpocalypse in 2038 is looming and there's no 'serious plan'

The year 2038 is still more than two decades away, but LWN.net editor and longtime Linux kernel chronicler Jon Corbet believes software developers should be thinking about that date now, particularly in the Linux world. Corbet raised the issue at his annual "Kernel Report" talk at the Linux Foundation Collaboration Summit in …

  1. Paul Crawford Silver badge

    Testing, testing!

    There are some ways to work round this and some things might just work. But testing is needed, and more importantly there should be STANDARDS for all those embedded applications that demand testing with post-2038 dates just to be sure.

    Currently 64-bit Linux works fine, of course, as time_t is natively 64-bits.

    Even today, as time_t is generally used as that (i.e. a specific data type and not the generic 'int' or even 'long'), if it were defined to be a 64-bit integer then most 32-bit systems would re-compile and be all OK as the compiler should do all the necessary stuff. What would be broken is things like file systems and other file formats where 4 bytes is explicitly used and that is all.

    Alternatively if the 32-bit integer was treated as unsigned then also most things would work. I tested the gmtime() function recently and found that 32-bit Linux "failed" post-2038 by design as it returned -1 to flag an error, same for the older MS VisualC++ 6 (also 32-bit). Ironically the old 16-bit MS-DOS C compiler got it right post-2038 if you treated time_t as unsigned!

    1. JamesTQuirk

      Re: Testing, testing!

      Testing, Testing, Would you know if postman was up you, if he didn't blow the whistle, Will Robinson ....!!!

      Warning, Warning Dr Smith is irate .... Get over the Robot from LIS, I nearly bought him, radio controlled, in 1986 @ MT Druitt in OZ, but thought I don't want to support that bit of crap, wish I had of bought for $ 3500 then ... so when 1mbit kernels's get here, where that theory gunna go, VM's will be history, in many ways ...

      1. Anonymous Coward
        Anonymous Coward

        Re: Testing, testing!

        @JamesTQuirk : Drunk are you, and in dimensions different am operating. Standard terms of reference no longer apply...

        1. JamesTQuirk

          multi-Re: Testing, testing!

          As a Pan dimensional, multi-Membrane being, I have seen your space time, it suck's, so do current batch of humans, but it is History, better luck next time ..., sorry, but I giggled .....

          SORRY I will pretend like it matters ...........

    2. Anonymous Coward
      Anonymous Coward

      Re: Testing, testing!

      Surely the upgrade to Windows Server 2037 will be completed by then and no one will need to care about legacy *NIX systems?

  2. Duncan Macdonald
    FAIL

    Testing is too expensive !!!

    At least that is typical management thinking. Given the number of idiots in management and the amount of code that is produced by the lowest (initial) cost by cheap third-world coding shops, I expect to see code with this problem still being produced in early Jan 2038.

    1. Dazed and Confused

      Re: Testing is too expensive !!!

      Shouldn't that be "Management is too expensive !!!"

      1. asdf

        Re: Testing is too expensive !!!

        Oh no. There is always money to be found for some manager/executive to promote his buddies. The ever growing middle management kudzu is what often needs to get culled but rarely does.

      2. Bleu

        Re: Testing is too expensive !!!

        'Ovepriced and inane'.

        There, fixed it for you. Agree with the sentiment, but the fatuous rule the world. Nature of bureaucracy and nepotism.

        Why do you think the brief experiment of some countries with genuine meritocracy (as part of competition with communism) was abolished everywhere but in parts of Asia well before the end of the Cold War?

        1. Fluffy Bunny
          Mushroom

          Re: Testing is too expensive !!!

          "Why do you think the brief experiment of some countries with genuine meritocracy "

          I must have missed that one. So please explain who experimented with a "genuine meritocracy"?

          - If you lived in Russia you would know it wasn't there. Toe the party line or go to a gulag.

          - It wasn't China. Toe Mao's line or you get shot.

          - It wasn't Cambodia. Toe the state religion (communism) or your whole family is shot.

    2. Colin 27

      Re: Testing is too expensive !!!

      I think its actually worse than that.

      Management are increasingly seeing the infrastructure their services run on as 'expensive' and 'not worth investing in' - despite the fact that its critical to their business. Put on top of that the ever increasing drive to generate profit means that upgrades just keep getting put off because the current solution 'just works' and its 'too expensive' to fix. Add all that into the mix and its a recipe for disaster!

  3. Spaceman Spiff

    It's time

    It's time the Unix/Linux world started migrating to a 64-bit time_t value instead of a 32-bit one for clock settings. Yes, some systems would be borked, but it would not be likely any more severe than Y2K was. That would keep us functional, time-wise, until some time when the sun goes dark and turns into a nova.

    1. Paul Crawford Silver badge

      Re: It's time

      You mean like we have has since 1985 (Cray UNICOS, first 64-bit implementation of Unix)?

      Or 1994 (Silicon Graphics IRIX)?

      Or 1998 (Sun Solaris 7)?

      Or 2000 (IBM z/OS)?

      Or 2001 (Linux becomes the first OS kernel to fully support x86-64, same year as XP 64-bit)?

      Or 2003 (Apple Mac OS X 10.3 "Panther")?

      [Shamelessly copied from http://en.wikipedia.org/wiki/64-bit_computing]

    2. justincormack

      Re: It's time

      Both NetBSD and OpenBSD have already, on 32 bit platforms. I think FreeBSD will soon. Linux is the laggard.

  4. RobbinMcDobbin

    The beginning of the Disco Decade...

    or 1/1/1970 at 0:00

    Please upgrade to at least 64 bit computing by 2038.

    If I live till then, I'll make my best effort.

    1. asdf

      rant alert

      Disco is pretty much the only thing Baby Boomers gave the world other than the idea that greed is a virtue.

      1. Anonymous Coward
        Anonymous Coward

        Re: rant alert

        I am really interested in hearing how you come to that conclusion. Please enlighten me.

    2. Christopher E. Stith

      time_t is used for more than the current time. Often software uses the same type to look forward... or would you like a credit card that expires in the past when it's first issued?

  5. Anonymous Coward
    Anonymous Coward

    Too late!

    While 64 bit Linux is fine, even if everything related to 32 bit Linux was fixed tomorrow there are many embedded Linux systems out there that will still around in 2038. Obviously no one cares if their Android device still functions in 2038, but how many cars have Linux running somewhere in them?

    Not to mention all the uses in random "internet of things" type devices monitoring critical infrastructure like power lines, oil pipelines, river gauges and so forth. When the time flips, do their alarms stop getting delivered, because the server taking the inputs sees the year 1901 and decides to throw out the obviously corrupt input? Don't worry, we'll find out about the pipeline overpressure when it ruptures and spills a few thousand barrels of oil in the countryside.

    1. Steve Knox
      Boffin

      Re: Too late!

      What systems are both vulnerable and will still be used in 23 years?

      If you know, list them, publicly, in fora where you know those people responsible for those systems will be paying attention.

      If you don't, shouting vague generalizations about it won't help.

      I cannot think of a single thing I have which relies on time values and is over ten years old, let alone twenty, but that's just me.

      I'm sure there some systems out there which will have to be fixed or replaced, but we already have a model of how to do that, which is closer to now that the problem we are discussing, and which was resolved in even less time than the 15 years between the present time and the trigger of the previous problem.

      Ironically, you've directly alluded to one of the common solutions to the Y2K issue: What do you do when 'the server taking the inputs sees the year 1901 and decides to throw out the obviously corrupt input?' Change the server to recognize that "obviously corrupt input" as coming from the next epoch.

      We did this for Y2K issues with a sliding window, so as we get later into the 2000s, those systems which absolutely cannot be replaced with one that takes more than two digit years will advance their window of what belongs to this epoc vs the previous one.

      Properly adapted, such systems could even survive Y21C. They'd just keep sliding that window. Of course, many systems weren't adapted that well, but nobody's gonna keep using these things for a full century, right?

      Problem solved -- and nobody needs to buy a new IoThingy -- for another 68 years or so, anyway.

      It wasn't too late in 1999, and it's not too late now.

      1. Anonymous Coward
        Anonymous Coward

        Re: Too late!

        "I cannot think of a single thing I have which relies on time values and is over ten years old, let alone twenty, but that's just me."

        Your bank's central IT system?

        1. JEDIDIAH
          Linux

          Re: Too late!

          > Your bank's central IT system?

          Which part exactly?

          Please be precise.

          Also please keep in mind that some of us have actually worked in banks.

          1. Anonymous Coward
            Anonymous Coward

            @Jedidiah Re: Too late!

            Read my reply. I was specifically commentarding on:

            "I cannot think of a single thing I have which relies on time values and is over ten years old, let alone twenty, but that's just me."

            I was being pissy because of the blanket disregarding of any possibility that there was anything he relied on that didn't use time values. I took the comment to mean time values in question, not specifically linux/unix.

            I should point out that I have not worked for a bank, but I have worked for a financial loan company and code over 10 years is not uncommon.

          2. Michael Wojcik Silver badge

            Re: Too late!

            > Your bank's central IT system?

            Which part exactly?

            Please be precise.

            Also please keep in mind that some of us have actually worked in banks.

            Oh, please. We do bank migrations all the time with source code that's more than ten years old. Twenty isn't particularly unusual. Generally no one knows what half that source code is for, or how much of it represents programs actually in use. And that's when they have source code; at least a couple times a year I see queries about decompiling binaries that no one can find the sources for.

            I've seen customers running OS releases that are more than ten years old.

      2. Anonymous Coward
        Anonymous Coward

        Re: a single thing I have which relies on time values and is over ten years old,

        I still use my Zaurus as an alarm clock, for some reminders, and for playing the odd game of clone scrabble - it's over ten years. I'm hoping it'll last twenty... :-)

        1. Bleu

          Re: a single thing I have which relies on time values and is over ten years old,

          I greatly admire the zaurus, mine is also still going.

          The claim to use it as an alarm clock does not ring true. You must be living in a place that is extremely quiet until the time-span where you wish to be awoken, if so, fortunate you.

      3. Pallas Athena

        Re: Too late!

        You make a critical error - you're talking about things that you own, personally. And indeed, very few people will own in 2038 something that has already been manufactured today. Cars have been mentioned - but very few passenger cars live to their 23th birthday (trucks, buses, ... that's another story). However, control systems in pipelines, chemical plants, power plants, ... - stuff that you or me will never own - do have livespans in the decades.

        1. Phil O'Sophical Silver badge

          Re: Too late!

          The problem isn't that bad things will happen in 2038, it's problems with 2038 and later. Take out a mortgage today, and it will have an end-date in 2040, so your bank better be able to cope with such dates today.

        2. DropBear

          Re: Too late!

          ...but very few passenger cars live to their 23th birthday...

          Funny you should say that. My car is 21 this year, and I fully plan using it for decades to come if it keeps up as well as it has. Yes, I'm writing this in Europe. And I need only look out the window to see countless more of the same. Also, considering the dashboard clock is the only thing in it with a concept of time (but not of dates), I'm quite confident it would have less problems with 2038 (other than age) than any car manufactured today...

          1. fuzzie

            Re: Too late!

            Keep in mind software frequently doesn't care about the exact date and time, but often use the timestamps to calculate durations, e.g. how long something took or when to wake up for something in the future. And something as inane as failing date/time stamps in log/audit trails could bring an application to a screeching halt.

        3. Myself-NZ

          Re: Too late!

          Funnily enough my son is driving around in his first car - a 30 year old Toyota Corolla. You might also wish to look at Cuba where people are driving around in things much much older than that. Having said that, the 30 year old Toyota has nothing in it resembling a computer and is thus immune from any time code problems.

      4. keithpeter Silver badge
        Windows

        Re: Too late!

        "I cannot think of a single thing I have which relies on time values and is over ten years old, let alone twenty, but that's just me."

        OK, a specific, concrete, example of something large and heavy that goes fast and that depends on an embedded system...

        The minicomputers in some diesel electric trains date from 1980s. These won't be Linux kernel based obviously, but a diesel electric train tends to have a long life...

        http://trid.trb.org/view.aspx?id=225737

        Perhaps the ones being built now do have Linux based controllers. Perhaps these are 64 bit. Perhaps if 32bit, then they will simply stop working (safely) on the relevant date and display an error code. Transport is, fortunately, conservatively managed and suppliers will take a careful change management approach to maintenance. Problems should surface in advance.

        The wider point: embedded systems are gleefully being added to many industrial and transport systems to reduce costs, improve monitoring, and provide hard data on use. This is an *expanding* market. Some suppliers will go bankrupt. It is possible that entire business models will be discarded, but will leave a layer of technology in racks in basements ticking away (e.g. DC mains power for 19th and early 20th century lifts/elevators in some cities - now mostly provided by local rectifier/choke sets).

        Timely and repeated restatement of this issue and the mitigations available will help to offset any disruption and is best started *now* as most of the systems that will be functioning on the date in question have yet to be designed/implemented.

        1. Danny 14

          Re: Too late!

          Nuclear power plants? Satellite systems? Weapons systems? Not just in western countries either.

          1. JEDIDIAH
            Linux

            Re: Too late!

            Hell. The electronic components of bleeding edge weapons systems are woefully out of date when those weapons go online.

            Good catch there...

        2. ralph058

          Re: Too late!

          All of the pipe lines, elevators, power plants,locomotives and lifts have ladder logic and use PCL. They may have a problem but net this one. With the prediction of self driving vehicles beinng readily available in ten years as an assumption, the insurance rates and reduction in labor costs. will drive most trucks and buses being made now off the road. The marketplace will drive ARM based toys to 64 bit in no more than three years. Anything else can be patched by changing time_t to unsigned. Just pick up the acorn, chicken little.

          1. Anonymous Coward
            Anonymous Coward

            Re: Too late!

            "Anything else can be patched by changing time_t to unsigned."

            Tried, tested, and proven.

            [Open]VMS did that for time_t back in 1998, related to the Y2K kerfuffle. It didn't affect "pure" VMS applications, as VMS has its own rather elegant internal time format, but stuff reliant on time_t (largely but not exclusively C and C-inspired stuff) needed updating.

            1. Michael Wojcik Silver badge

              Re: Too late!

              "Anything else can be patched by changing time_t to unsigned."

              Tried, tested, and proven.

              For some applications. Not all. Go read the archives of comp.lang.c from 1999 - people identified many codebases that relied on treating a time_t as a signed int and getting a positive value. Typically that had to do with comparing for <0 rather than (time_t)-1 to check for errors.

              But who am I to disagree with the Reg readership hivemind? As usual, it knows all.

      5. Jess

        Re: relies on time values and is over ten years old, let alone twenty

        The machine I'm reading this is is over ten years old.

        1. Green Nigel 42

          Re: relies on time values and is over ten years old, let alone twenty

          Ok, my Dell Inspiron 6400 I've posted this may only be 9 years old, but it is running 32 bit Linux, solid as the proverbial Sh1t house and shows every intention of going on & on & on. (where did I hear that before?)

      6. Michael Wojcik Silver badge

        Re: Too late!

        I cannot think of a single thing I have which relies on time values and is over ten years old, let alone twenty, but that's just me.

        Right. It's just you.

        I have a 23-year-old HP Laserjet 4m here which I just used today. I have a 22-year-old Panasonic VCR which, alas, is not Y2K-compliant, but fortunately I no longer need it to know the correct date (as I no longer use it to record). I did, though, do some programmed recording with it as recently as 2003; that required a little fudging of the date but fortunately nothing worse.

        We did this for Y2K issues with a sliding window

        Many applications were adapted for Y2K with a sliding window. Many others could not be.

        All you need to do is read RISKS regularly to understand that complex systems fail in complex ways, problems are worse than you think, and there are no silver bullets. But apparently (and unsurprisingly) IT is still full of people who don't get that.

      7. davcefai

        Re: Too late!

        HP95 palmtop.

    2. Richard Altmann

      Re: Too late!

      @ DougS

      Dear Sir, your example is not chosen very wise. In 2038 there will be no more fuel burners on the roads.

      At that time there will be prohibition on vehicles using fossil fuel. Except maybe agricultural vehicles.

      And as for the pipelines, they will be obsolete for the same reason. So don´t worry about that.

      Just wait until the fracking technology backfires and destroys the drinking water resources in the U.S.. Drinking water will be more costly than fuel. The fuel strategy of the U.S. has always been to suck out fuel rich countries before touching their own reserves even at a high cost. The reason is, to be the last empire to be able to run a fuel driven army. Enabling them to take over the rest of the world. That strategic paper is out there on the internet. It´s obolete as well now since the beancounters took over and sacked the strategists. U.S. has become the number one oil producer in less then 10 years, making oil as cheap as its never been. The biggest selling car in the U.S. is a Ford pickup. And sales can only be furthered by cheap fuel prices. Who the fuck needs such a monster on wheels accept farmers? Small d**cked a**holes with a mental deficit. Which, looking at the sales numbers, are a lot. The good thing is that the U.S. is spoiling their fuel reserves for what looks like economic growth and at the end have nothing left to refuel their tanks, warships and airplanes. The downside: they still got nukes. The upside: They cannot nuke a region to get hold of their water resources and have no fuel to occupy this regions because they spent it on Ford Pickups.. In 2038 California and Nevada will be inhabitable due to lack of water. I´m on my way back to central Africa where the banana and coffee grows without pesticides and the cattle is not full of shots of antibiotics.

    3. Chairman of the Bored

      Re: Too late!

      Understand what you are saying, but many of us develop embedded systems and I for one am not particularly concerned about t your infrastructure examples.

      Why? Most real time (critical) code does not use time_t for several reasons: first is most control applications could care less about system time/date. Logging and admin is usually not handled in your real time, critical code - that's sent to general purpose machines elsewhere so the beancounters get their beans. Second, for applications that do care deeply about time/date, experienced system developers do NOT depend on system time because of its notorious errors and unreliability, especially in harsh environments. Third, in this day and age of GPS spoofers and wankers mis-configuring NTP servers so badly I don't know what decade I'm in, many developers adopt a healthy attitude of total distrust for time_t

      Banking and financial... That concerns me.

  6. mafoo

    db

    all those databases with timestamps stored as int11

  7. Gordon 11

    but how many cars have Linux running somewhere in them?
    And how much of this is dependent on absolute (rather than relative) times?

    If they are running to absolute time, how accurate do you expect it to be in 20 years time, given that I doubt that it has a network connexion to run (S)NTP.

    1. Z80A

      Switch it off, wait a few minutes, switch it on again

      That will sort out most of the clockalypse bugs in embedded things. It always worked before.

  8. Anonymous Coward
    Anonymous Coward

    The story that keeps on giving ...

    ... until 1970 arrives (for the third time)

  9. thames

    The problem is in applications

    As already mentioned, this has already been corrected in the Linux kernel itself for 64 bit versions, and 32 bit hardware is fading from the scene rapidly. The ext3 file system which was mentioned has been obsolete for some time, having been replaced by ext4, which itself by the way is on the way to being replaced by its own successor. There probably aren't a lot of ext3 systems around even today.

    The real problem however is with application software. A new 64 bit time has been provided, but that doesn't patch existing applications. The old 32 bit time is still there for backwards compatibility. The problem is going to be what to do about software that doesn't get upgraded to use the new 64 bit time interface.

    I haven't heard Corbet's recent talk, but previously he was writing about the pros and cons of trying to find some way to change the older 32 bit time value without breaking too many existing applications. In other words, to somehow give those apps an automatic upgrade. Various ideas have been discussed, but nobody feels confident enough to simply go ahead and do any of them.

    If there was only open source/free software to worry about, we could scan the source code of all the common software for 32 bit times and to patch the software to use 64 bits. However, there is also a lot of existing proprietary software out there where that is not an option. Customers have running code which may not be maintained anymore by the vendor, but it is running (for now) and there is a strong reluctance among Linux developers to do anything which might cause problems for them.

    A creative solution may be found, or alternatively the answer might be to tell people to suck it up and upgrade their software to 64 bit values some time before 2038. It's a matter of balancing the relative risks. The big problem of course is going to be with the "never, ever, ever, upgrade" crowd who aren't going to apply either sort of solution.

    The problem by the way isn't limited to unix-like systems. Back in 1999 I was working on finding and fixing the Y2K problems in industrial machinery for a large global manufacturing company, and there were 2038 roll-over issues with 8 bit industrial controllers which were made by one of the largest companies in the business. There was no unix/Linux/whatever OS involved. The software was running on the bare metal. The system designer just happened to use the same date epoch and date size. I noticed that, but put the issue aside as not being relevant to Y2K (I found good solutions to all the Y2K issues elsewhere though).

    I expect there are loads of other embedded systems out there which are similar. It's a general issue industry wide.

    I also wouldn't count on Windows systems being immune to this issue. As noted above, the issue isn't with the Linux kernel itself, where the problem is already fixed for 64 bit. The real problem is with application software and third party libraries. There are plenty of those around which might be doing date handling in ways which produce unexpected results regardless of how the OS itself handles dates.

    1. roger stillick
      Coat

      Re: The problem is in applications... so start over

      Keeping track of our IP and keeping a platform working is the ONLY need for us...in the last 30 years we've binned so much SW and kit that it isn't even worth mentioning...

      Foward to today... our workstations n better are 64bit Linux, our throw away terminals are 32bit Linux salvaged from MS kit made obsolete by newer MS OS's...Our IP is stored as PDF's on Rust and Silicon...

      IMHO= when the time comes, we will simply change, we always have, nice article, there will be many changes B/4 then... remember= replacing a single IBM PC hard drive will cost the same as 3 more SOC modules for our massively parallel matrix mule project... would rather play w/ the mule...RS.

      1. roger stillick
        Coat

        Re: The problem is in applications... so start over, P2

        i'm an old ANZII graphics programmer, which could be emulated in a 256bit OS using an updated 256 ASCII code... maybe get my toumbstones back... really miss writing those pre-easter eggs.

        So why not write a bloated 256bit OS for 64bit processers ?? would use a 4 cycle word, be 4 times slower, with today's applications we won't even see the reduction, but oh boy will there be an opened up data structure and date problems that will not be a problem for the rest of this millennium... RS.

    2. Paul Crawford Silver badge

      Re: The problem is in applications

      It also depends on how well the applications were written, and how they are linked. For example, if they only ever used the libc code for time calculations (mktime() gmtime() etc) then having a patched libc on the 32-bit system would allow this to be put off until 32-bit unsigned overflow, which is around 2106

      However, if statically linked or doing things with time_t based on it being signed, then its going to have problems. Also note (as already covered) this is not a Linux problem as such, it is a C language problem and anything similarly UNIX-y that uses the time_t. A lot of MS software could well be using the C library, etc.

      So really this is more a 32-bit application/data problem, and only code audits and (more importantly) testing will reveal what will actually happen.

      1. Anonymous Coward
        Anonymous Coward

        Re: The problem is in applications

        "However, if statically linked or doing things with time_t based on it being signed, then its going to have problems. Also note (as already covered) this is not a Linux problem as such, it is a C language problem and anything similarly UNIX-y that uses the time_t. A lot of MS software could well be using the C library, etc."

        Or stuff based on time_t being exactly 32 bits, such as in structured types or disk I/O. That's why ext3's noted as trouble, because its timestamp is based on the 32-bit time_t and writes that format to disk. And since ext3's structure is spelled out concretely, there's no way to change it without all existing installations breaking. So ext3's basically dead-ended if an embedded device uses this format internally and lasts beyond a few decades.

        1. JamesTQuirk

          Re: The problem is in applications

          So me playing 8 bit & 16 bit games in wine, & other Emulators, breaks law of physics or something ?

          No I still like wiping a swarm of b17's in SWOTL in 3 passes in a me262, running in DOS5, the Kaypro CPM VM is work in progress ....

          Some of key to running old games/apps is having a VM or Virt HDD as fat8 or fat16 bit format, give it what it really wants, and they are happy ..

          As you can control the "clock" in VM, this is issue when ?

          Time is a relative thing, cause all my relatives have my things most of the time ? ....

          And that will apply to NextGen emulators too ...

          1. Charles 9

            Re: The problem is in applications

            I don't think consoles kept a real-time clock until around the 5th Generation (the PSX generation) excepting the Neo-Geo, which was based on arcade boards (some arcade boards kept a clock for recordkeeping purposes).

            As for FAT, it's luckier than ext2/3 because of its datestamp format (time is not an issue, it uses two bytes for time-in-day, which is enough to cover an entire day; its only catch is that it's only precise to within two seconds). It dedicates 7 bits to the year and uses 1980 as the epoch. Meaning it won't run afoul of calendar overflow until the end of the year 2107. Beyond that, it will probably be easier to have any VM still emulating an old DOS like this to pretend it's an earlier year.

    3. Vic

      Re: The problem is in applications

      There probably aren't a lot of ext3 systems around even today.

      There are. ext4 is really quite bad at dealing with improper shutdown - power failure and the like. The configuration I and many others use is to create a (smallish) root filesystem with ext3, and use xfs/ext4/whatever for the other filesystems. This means that a machine can usually boot properly after a hard power-down.

      Vic.

  10. Anonymous Coward
    Anonymous Coward

    Could this already be a problem ?

    2038 is well within the range of calculations that would be done *now* for pensions, etc.

    Could we already have some suspect data stored somewhere, waiting to bite our ass ?

    1. thames

      Re: Could this already be a problem ?

      A lot of applications use their own or third party date libraries, because date calculations can be quite complex. People want to know things like what day of the week New Year's falls on, and that's not something the OS kernel worries itself about. If those applications level date libraries use 32 bit time stamps, then yes, there might be existing problems. This problem can be found on any operating system though.

      If there is a problem in long term financial calculations, it's unlikely to be due to the Linux kernel, since most such systems would be running on 64 bit hardware, and 64 bit Linux uses 64 bit time values. For 64 bit Linux, the issue is going to be the year 2262.

      If you are using a 32 bit kernel, then the core timekeeping code also keeps time using 64 bit values.

      The real problem is going to be getting the writers of applications software to update their code if they are using 32 bit time values within their applications. Many applications may already be using 64 bit time code internally for date calculations because they already have to deal with future dates. The issue with 2038 will be if the application asks for the current time in 32 bit format instead of 64 bit format.

      Here's an article which Corbet wrote on the subject last summer.

      http://lwn.net/Articles/607741/

      He said:

      "The harder step, of course, is ... get user-space developers to change their code over. That will require cooperation with user-space developers from the C-library level on up and a lot of thought into how this change can be made with a minimum of pain."

      1. Anonymous Coward
        Anonymous Coward

        Re: Could this already be a problem ?

        "For 64 bit Linux, the issue is going to be the year 2262"

        Erm, no. For 64-bit time_t the problem will be some time around 15:30:08 on Sunday, 4 December 292,277,026,596

        1. Anonymous Coward
          Anonymous Coward

          Re: Could this already be a problem ?

          "some time around 15:30:08 on Sunday, 4 December 292,277,026,596"

          Inaccurate.

          The rotation of Earth is slowing down and we'll have a 25 hour day in ~200 million year mark. We'd already have by then several leap seconds added every minute.

        2. DropBear
          Trollface

          Re: Could this already be a problem ?

          ...what was that in Stardate...?

        3. thames

          Re: Could this already be a problem ?

          Anonymous Coward said: "Erm, no. For 64-bit time_t the problem will be some time around 15:30:08 on Sunday, 4 December 292,277,026,596"

          Read the LWN link that I posted in my comment above and look down in the comments for discussion of date roll-over. The 64 bit time value uses a higher resolution than the 32 bit time value, giving year 2262 as the next date roll-over. The article itself discusses the internal date format.

          Some of the confusion which is arising here comes from there being several different issues which are being rolled together under the label of "2038". There is internal time keeping code inside the Linux kernel, and there are time references which are used by various sub-systems (e.g. file time stamps) and applications software. As someone else has pointed out, this is really a 'C' library issue, and the Linux kernel developers have just been handling their little corner of an industry wide problem. There were several dozen system calls that were affected by time in some way.

          In brief, the 32 bit value is the number of seconds since the 1st of January 1970 (the "epoch"), but the 64 bit value used as the counter inside the Linux kernel is the number of nano-seconds since the epoch. This applies to both the 64 bit and 32 bit kernels. Recent changes to the kernel involved getting rid of remaining 32 bit time-keeping references. I believe there used to be separate high resolution timers versus "low resolution" time-keeping. This has basically been unified to one 64 bit system internally.

          How the Linux kernel handles time keeping internally is however a different issue from how applications software makes use of time values. The time-keeping value can be exported in different formats as seconds or nano-seconds. All the kernel developers have done is make sure their internal "clock" doesn't roll over. They haven't made all the application software that is out there look at a 64 bit time value (which may be in seconds). As Corbet discusses in his article, this is where the real problems will be. As I've mentioned above, this is an industry wide problem that potentially affects all operating systems and even embedded systems that don't use an OS, depending on how the date libraries handle date calculations internally.

          Also note that there are other time roll-over problems, many of which are going to be much more difficult to solve. For example DVB digital video standard includes a 16 bit time that also overflows in 2038. The ATSC digital video system has a 2048 roll over problem. NTP (Network Time Protocol) has a time stamp which rolls over in 2036. There are loads of different unrelated things which roll over in the 2106/2107 time frame.

          These problems aren't going to be fixed by fixes in the Linux kernel. It's really just a generalization of the Y2K problem involving a wide variety of systems, many of which are completely unrelated to Unix or Linux. It's just convenient to label them as the "2038 problem", even if the critical date falls on another year.

          1. JamesTQuirk

            Re: Could this already be a problem ?

            So that relates to 128b 256b 512b or "the" mega kernel how ??

            Thinking 64 bit is end is weird ....

          2. Anonymous Coward
            Anonymous Coward

            Re: Could this already be a problem ?

            "Erm, no. For 64-bit time_t the problem will be some time around 15:30:08 on Sunday, 4 December 292,277,026,596"

            "Read the LWN link that I posted in my comment above"

            If you re-read both the original article and my comment you'll see both make it clear that what's being discussed is time_t, not ktime_t which is a Linux-only kernel implementation detail. Yes there's an issue with Linux's ktime_t as well but it's not *this* issue. ktime_t is an issue that doesn't really affect anything other than the Linux kernel, whereas time_t is defined in IEEE Std 1003.1, AKA POSIX, so in principle the issue affects any POSIX-compliant OS, not just Linux, despite the article's Linux focus.

            Whilst POSIX defines time_t as an integer type it does not specify how many bits it should be, the problem is if time_t is defined to be 32 bits. If time_t is 64 bits, it doesn't run out until the year 292,277,026,596, as I said.

            1. thames

              Re: Could this already be a problem ?

              Anonymous Coward said: "Yes there's an issue with Linux's ktime_t as well but it's not *this* issue. ktime_t is an issue that doesn't really affect anything other than the Linux kernel,"

              We were obviously talking past each other then. What Corbet has talked about as being "fixed" is ktime_t, which means the "clock" which the kernel keeps time with and which can be queried by applications (via the system C library) for the current time (or schedule future events) will now not roll over until 2262. Previously, there was a mixture of 32 bit and 64 bit counters to handle both time keeping and high resolution timing tasks. These have been unified into a single 64 bit nano-second resolution system which can also export the time in seconds as 64 bit or 32 bit values. Some time before 2262, if Linux still exists, the developers will have to deal with the 2262 roll over problem.

              The user space time_t value you are referring to is now at this point an applications and third part library issue. This is what Corbet identifies as being the hard part although it has nothing directly to do with the Linux kernel itself. This problem is not fixed and is something that is unlikely to be fixable by just making changes to the operating system.

              As I mentioned in previous comments, this isn't really a Unix/Linux problem, but something that is industry wide, and with more dates than just "2038" involved. It's the Y2K issue writ large and something that may be a lot harder to deal with since fixed word size time stamps are built into protocols, not just applications.

        4. Anonymous Bullard
          Coat

          Re: Could this already be a problem ?

          the problem will be some time around 15:30:08 on Sunday, 4 December 292,277,026,596

          I was putting that date in my calendar, but the damn thing crashed.

    2. jonathanb Silver badge

      Re: Could this already be a problem ?

      If you are 65 in 2039, you could well have taken out your first pension in 1992, so I would imagine that if there is a problem, someone would have spotted it by now. Most people these days taking out pension policies will be retiring after 2038.

    3. John 156

      Re: Could this already be a problem ?

      Pensions systems tend to hold dates in decimal form so that they can be displayed or printed directly. They would then pass dates to a calculation routine to determine elapses. The 32 bit problem would certainly have have been spotted because clients are sent statements at initiation and annually defining their future projected entitlements at maturity.

      Incidentally I did Y2K for a major; unfortunately, someone else did the rates retrieval system which used six decimal dates, a problem they surmounted by deciding that years higher than 30 were 20th century otherwise 21st! I pointed out, too late, that it was always possible to calculate the year accurately simply by using the current date and an assumpotion that people did not hold a pension for more than 99 years.

  11. Mark 85

    1938 or so?

    – back in the early days of Unix, when 2038 was almost a century away –

    Really.... a century? That mean Unix was designed in 1938 or there about?

    1. Yet Another Anonymous coward Silver badge

      Re: 1938 or so?

      68 years is closer to a century than not

      1. Richard Taylor 2

        Re: 1938 or so?

        But rounding up to the nearest century just to get a nice sentence is pretty sloppy

      2. Anonymous Coward
        Anonymous Coward

        Re: 1938 or so?

        I know that maths and even simple sums are hardly understood by those brought up in the age of pocket calculators and mobile 'phones. But if someone reading this thinks that 68 is a fair approximation to 100, this is rather worrying. One could round it, more correctly, to 50 (that's the number of years in half a century in case you can not work it out). In the context of time, assuming that 1this 1970 date is widely used as the base now, that is just 45 years ago. What surprises of a similar sort will another 45 years bring? One can not assume that technology will continue to be developed at the same pace. It is even possible that it will go into reverse - just as much education, business practice and "democracy" seem to be doing. Without a strong, supportive culture and education system, technology will suffer, just as it did in the dark ages. There is nothing magic or immune about it. Assuming that, 23 years from now, some clever agreement will be in place that prevents the problem is not supported by form over the long term, no matter how impervious to change and events the world may seem.

        Perhaps you are an economist? Working for a national government? Or just a senior manager trying to calculate his bonus in a bad year or the savings by "offshoring"? No wonder most economies and a lot of businesses are in a bad state.

    2. Mage Silver badge
      FAIL

      Re: 1938 or so?

      when 2038 was almost a century away

      Since when is about 60 years almost a century?

  12. Peter Prof Fox

    Answered years ago!

    Nobody needs to know 12 minutes past three on the 4th September 2044.

    What you need is DATES. You know, the things humans have been using for thousands of years.

    Hey! Dates might not be moments in time as per timestamps but whole months or whole years or 'not-known' or 'before we started counting'.

    Go to http://vulpeculox.net/day/ for what you need to know.

    1. Daniel B.
      Facepalm

      Re: Answered years ago!

      Processes do need microsecond precision. You fail at UNIX. Or OSes in general.

  13. FrankAlphaXII

    UNIX?

    Leaving the Linux kernel aside, does anyone have an idea of which commercial UNIX products (as well as *BSDs) have this issue and which have been fixed already? I can't seem to find a reliable list anywhere.

    1. oldcoder

      Re: UNIX?

      I believe they are all 64 bit systems now, and the system uses 64 bit counters... (Solaris and AIX are the ones I know have been updated, but I don't know about others for sure. Since they are based on AT&T System V they should all be 64 bit counters. The BSD based ones are also likely updated already).

    2. Christian Berger

      OpenBSD

      I think OpenBSD is rather far with it, they kinda follow a "nudging" policy. They just implement the necessary changes in their operating system, and then file bugs to the other projects. After all usually it's just very small changes you need to make.

      So yes, it can be a bit of a problem, but unlike such deadlines in the Windows world you have the source so you can change it.

    3. Alan Burlison

      Re: UNIX?

      "Leaving the Linux kernel aside, does anyone have an idea of which commercial UNIX products (as well as *BSDs) have this issue and which have been fixed already?"

      One of my colleagues has written an article that describes what we are doing about this issue for Solaris, as part of a larger LP64 program - see https://blogs.oracle.com/alanc/entry/lp64_bit_by_bit. There is also a link to a good description of the different options being considered for Linux - see http://lwn.net/Articles/608571/ The LWN link explains that Linux community want to keep open the possibility of running a 32-bit Kernel on embedded devices whereas for Solaris:

      "Engineers at Sun long ago debated a “large time” extension to the 32-bit ABI like the large file interfaces, but decided to concentrate efforts on LP64 instead. Because Solaris is not trying to maintain 32-bit kernel support for embedded devices, that is not a problem we have to solve as we move forward. The result should be a simpler system, which is always a benefit for developers and ISVs."

  14. JamesTQuirk

    This story is "wide-up", do you really believe, same OS's as 2day will run tomorrows Architectures, Change is only constant in IT, Data will converted & our robotic AI Overlords, will catalog it, as VM's to run in "stasis jails" that the data to be analyzed ...

    ;)

    1. Charles 9

      Change may be a constant in IT, but change is discouraged in many other industries, especially heavy industry and embedded systems where the operative phrase is, "If it ain't broke, don't fix it." Indeed, when IT mixes with other industries like manufacturing, there tends to be culture clashes: for example, software meant to last years controlling hardware meant to last decades.

  15. Tom 7

    I dont think ther will be many 32bit linux OSes still running then

    I'd put good money on there being a lot of Cobol banking stuff which has some 32bit time stamps in it.

    It might even pay enough to be worth coming back from the afterlife to fix it!

    1. Anonymous Coward
      Anonymous Coward

      Re: I dont think ther will be many 32bit linux OSes still running then

      Surely any sensible COBOLer would process dates as yyyy mm dd (with a library of supporting routines if necessary)?

      Anybody with a clue has been aware of the 32bit time_t problem since shortly after Y2K became an issue (which may well rule out the last decade or so of college leavers?). Sensible code where the issue is relevant has already moved to using a 64bit value for time_t.

      You can use 64bit time_t whether or not you're on a 64bit CPU and whether or not you're on a 64bit OS. You can even do it on Windows with Studio: https://msdn.microsoft.com/en-us/library/1f4c8f33.aspx

      Good to raise awareness. Not good to overhype (as seems to be happening).

      Have a lot of fun.

  16. Bloodbeastterror

    Nah...

    Y2K was a big fat nothing. Every computer system worked just fine. There was never any need to panic. Millions/billions down the drain. I know this because 2000 came and went without any problems at all.

    (As it happens, I worked on Y2K and I giggle at the opinion above voiced by the general public. I hope this one gets a bit more visibility).

    1. Anonymous Coward
      Anonymous Coward

      Re: Nah...

      Yup - but have managers and bean counters learnt anything from having to pay a lot of money to fix very real problems at the last moment? I got to use my Cobol and OS360 knowledge (originally learnt as a yahh boo bored activity at university plus a holiday job at an accounting company) at rates that were truly eye watering. Paid the mortgage :-)

    2. Tristram Shandy

      Re: Nah...

      Well I changed a lot of COBOL code at the time that would have gone titsup if it had been left. The software had been written at a time when where saving two bytes of storage and only using the last two digits of the year was common practice. Clock cycles were also counted and 2 digits reduced the number of clock cycles as well.

      1. Bloodbeastterror

        Re: Nah...

        Alas, Tristram, it looks very much as if you never got to my second paragraph... :-)

        1. Doctor Syntax Silver badge
          Facepalm

          Re: Nah...

          "Alas, Tristram, it looks very much as if you never got to my second paragraph... "

          According to the down-votes it looks as if a lot of other people didn't either. So have an up-vote from me to help counter-balance.

          As I've written here before I worked on Y2K as well and the client's bean-counters decided to demonstrate it really was a problem. What they actually decided to do was to wait until mid-January before they'd let us cut over to the new system (which they'd already tested & accepted) because they didn't want to take the risk of using something new before they'd completed their year-end stuff. This despite being warned. Yup, Y2K was a thing.

        2. Hud Dunlap
          FAIL

          Re: Nah...@blood beast error.

          It is clear that Tristan did read your second paragraph. Just because you worked on it and didn't see a problem he did. If he hadn't been one of the people fixing things ahead of time there would have been a huge issue.

          I replied to your original post and I did read your second paragraph. Just because you didn't see a problem in your own little world doesn't mean that other people didn't.

          1. Bloodbeastterror

            Re: Nah...@blood beast error.

            Apparently I'm going to have to work on my communications skills. Or maybe other people need to read more carefully before hitting the downvote button.

            Do tech people really follow the stereotype of having no sense of humour? Maybe I don't after all, who knows? :-)

            "Baldrick, to you irony is like bronzey and steely, isn't it?" Ben Elton, Blackadder.

        3. Tristram Shandy

          Re: Nah...

          I read it and it didn't make sense......Having re-read it I now know what you were rather ham-fistedly trying to say (I think).

          1. Bloodbeastterror

            Re: Nah...

            Point taken... :-)

      2. Tom 7

        Re: Nah...

        I do worry that there may come a time where AI loads a piece of old code and it hides due to agoraphobia.

    3. Hud Dunlap
      FAIL

      Re: Nah... @bloodbeasterror

      No they didn't. Back when I worked for a Semiconductor OEM I spent many hours testing equipment to make sure it didn't have problems. My employers equipment didn't. Some of the other vendors that I worked with had major problems. Such as complete lockups.

      The reason we didn't have major issues with Y2K is because everyone was testing ahead of time.

      The biggest problem with Y2k was the H1-B visa. The Y2K bug was the "reason" the U.S. started letting in so many foreign tech workers.

  17. Davie Dee

    isn't Linux running on just about every embedded computer out there, it is arguable that by then not a lot of that stuff will still exist but the OP is talking about sorting out that now so we don't have the same worry then.

    sounds fairly sensible to me!

  18. Anonymous Coward
    Anonymous Coward

    Much ado about nothing

    This is all just a storm in a time_t cup.

    Sorry, I'll get my coat...

  19. Anonymous Coward
    Anonymous Coward

    Two solutions

    You can either use a bigger time_t, or design your software to cope intelligently with time_t overflowing. With the first solution you're just setting yourself up to have the 2038 problem all over again in the year 292279027178, so I'd go with the second solution, which also has the advantage of being technically much more interesting.

    1. Bloodbeastterror

      Re: Two solutions

      Wow, downvoted? Some people really do have humour bypasses. :-)

  20. Trollslayer

    Not just Linux

    DVB - Freeview, VM and Sky etc. have the same time format.

    Freeview is the difficult one as the others manage the receivers.

    1. R W Rodway

      Re: Not just Linux

      Actually that's a slightly different date overflow problem. Dates in DVB are represented as a 16 bit modified Julian Date and a 6 digit BCD encoded time within the day.

      A modified Julian Date is the last 5 digits of the full Julian date. The current full Julian date is 2457074

      so the modified Julian date is 57074. 16 bits mean that 65535 is the last modified Julian date that can be represented in the DVB format, which is 22nd April 2038

      Almost the same date and definitely a problem, but a very different derivation

      --Richard

      1. Doctor Syntax Silver badge

        Re: Not just Linux

        " the last modified Julian date that can be represented in the DVB format, which is 22nd April 2038"

        Maybe not such a problem.

        The key thing is that DVB only needs to be interested in dates after it was introduced. It will never have to deal with learlier. So let the date roll over. After 57074 the next Julian number will appear to be 00000 which will unambiguously signify 23rd April 2038. Introduce this into the standard now so that manufacturers can start building firmware on this basis PDQ.

        In 2038 very old kit for which a firmware update either wasn't available or wasn't applied will become obsolete but this isn't anything new with DVB; remember the entire analogue system or the early STBs that could only cope with a few channels?

        Of course this assumes that the Ministry of Fun haven't flogged off the DVB spectrum to mobile operators.

  21. davcefai
    Flame

    Somebody Else's Turn to Suffer

    Listen here you lot. Y2K was bad enough. We worked for months to fix it and got through with flying colours. For my part only one (non critical) field on a GUI misbehaved on the 1st January and that was because, according to the supplier, they changed the specification for the function. ("We'll be sending you the compiler upgrade")

    So a few days later the know-it-alls were trumpeting that there never really was a problem.

    Now with the progressive dumbing down of non-technical management I forecast that not enough resources for fixing and testing the 2038 bug will be made available. (After all Y2K wasn't a problem was it!) My condolences to those whose job requires them to somehow make bricks without straw.

    So I suggest that those of us who may be around at the time should read all the pre-Y2K articles about surviving it. Have ready cash, canned food, extra petrol for the car etc. Thankfully I am retired but at 88 I don't really want to be patching anything - not even my alarm clock.

  22. Anonymous Coward
    Linux

    Oh no! Because 2038 was the year Linux was going to make it big on the desktop!

  23. GitMeMyShootinIrons
    Pirate

    Is this Y2K all over again?

    Hope so. That's my pension pot sorted.

  24. Jonathan 27

    Better they ignore it

    You know, it's in my best interest that no one does anything about this. If it's a big rush at the end they'll be willing to pay all us developers much more to get it done in time. I'll be 56 in 2038 so I'll still be in the workforce by then, I'm sure a bunch of you are in the same situation.

  25. DrXym

    I really don't see the big deal

    Redefine time_t as 64-bits. As it is already in some configurations.

  26. Richie 1

    > Specifically, that's going to happen at exactly 03:14:07 GMT on January 19, 2038.

    Being picky, doesn't the exact fail time depend upon how many leap seconds get added between now and 2038? Since leap seconds are unpredictable, we can't know the exact fail time until we get much closer to the fail date.

    1. Roland6 Silver badge

      > Specifically, that's going to happen at exactly 03:14:07 GMT on January 19, 2038.

      Also being picky, that is local system time, which isn't necessarily the same as world atomic clock time..

      1. AndrueC Silver badge
        Boffin

        Also being picky, that is local system time, which isn't necessarily the same as world atomic clock time..

        Ah but most (probably all) modern OSes are using UTC (aka GMT) internally. Local time is a user feature that modern OSes only bother with as a convenience for us. Anyone who has had to muck about with date/time processing knows that you never store or manipulate local time. It's too much hassle and too error prone.

        You can see this on Windows (and presumably on Linux as well) in a month or so when the clocks go back. Create a file just before DST kicks in and note the creation time. Check it after DST has started and it'll have changed by an hour. That's because the file system stores the time as UTC and applies a locale specific conversion when displaying it. DST yields a different result for that conversion.

        1. Anonymous Coward
          Anonymous Coward

          filesystem time on a Window box filesystem

          "You can see this on Windows (and presumably on Linux as well) in a month or so when the clocks go back. Create a file just before DST kicks in and note the creation time. Check it after DST has started and it'll have changed by an hour. That's because the file system stores the time as UTC and applies a locale specific conversion when displaying it."

          You might want to think about (or look into) whether NTFS and FAT (and FAT32) all behave the same way in this respect.

          [Hint: they don't.]

          1. AndrueC Silver badge
            Meh

            Re: filesystem time on a Window box filesystem

            You might want to think about (or look into) whether NTFS and FAT (and FAT32) all behave the same way in this respect.

            That's true but you might want to consider that it's largely irrelevant. FATx is pretty much only used on USB sticks these days (and even then NTFS would be preferred unless portability with another OS was a factor). NTFS has been the default file system for hard disks since Windows XP. As a consequence it's pretty safe to say that 99.9% of documents created under Windows on a local disk file system will be created on an NTFS volume.

            The 'Windows file system' is NTFS and has been for over a decade. FATx is just a legacy file system that Windows (in common with most OSes) supports for inter system compatibility reasons and is mostly only seen on portable devices.

            1. Charles 9

              Re: filesystem time on a Window box filesystem

              In any event, FAT16/32/exFAT should be good for the rest of the 21st century. Its date format is good until 2107 but is only certified to 2099. Since FAT32 gets cumbersome beyond 100GB, which we're already approaching for USB sticks and SD, and exFAT is patent-encumbered, I suspect they'll be superseded well within 85 years. ext4 is good until 2500+, by which time a successor is expected.

      2. Christopher E. Stith

        That's not how the epoch time works. The time zone conversion on a typical Unix system is applied at input and output time. The time internally is all UTC.

    2. Yet Another Anonymous coward Silver badge

      Couldn't we solve the problem by subtracting lots of leap seconds before then ?

      1. Charles 9

        Perhaps an alternative would be to separate days and portions of days into two separate 32-bit values, perhaps not as a realtime clock value but perhaps for storage within a filesystem. Say use the absolute Lilian Day as the day variable (its epoch is the day the Gregorian Calendar went into effect: 15 Oct 1582). That gives it four billion days to work with and room to add one or two placeholder values for invalid, unknown, or indeterminate dates. With a signed 32-bit value for time of day, you can still be precise to within 1/10,000 of a second which should be sufficient for most purposes (unless one can point out a general-purpose reason for nanosecond filesystem precision) AND still have room for the odd leap second (by separating day from daypart, leap seconds become easy to insert without trashing the rest of the calendar) while holding the negatives for specialized or placeholder time values.

  27. Aitor 1

    I will be retired

    So.. why lose company time(money) solving this?

    1. Charles 9

      Re: I will be retired

      Tell the bean counters, "Lose a little now, or possibly lose a lot later."

  28. another_vulture

    2038 is a 31-bit problem, not a 32-bit problem

    The 32-bit fields used everywhere to store UNIX time (not just Linux time) will roll over in 2106. However, any code the treats the field as a signed integer will roll over in 2038. The fix is therfore easy and does not require changing any data files, just code: use the same field but make sure to treat it as an unsigned integer.

    This gives us until 2106 to quit using old file systems whose headers have 32-bit fields, and quit using application file formats that use 32-bit seconds. This class of fixed is a whole lot harder than code fixes as it requires that all the old file be converted.

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

  29. Jon Bright

    I wish people would shut up about this problem

    How else am I supposed to plan for my retirement? I've been reckoning with a few highly-paid consulting gigs in 2037, in the (by then) nearly-forgotten language of C.

  30. Anonymous Coward
    Anonymous Coward

    So basically...

    ...given that all the other major Unices and related OSes are already fully 64-bit for time_t and have been for a long time, with only Linux lagging behind (as usual). this is just another reason NOT to use Linux in anything remotely important or remotely long-lived, it would appear.

    Solaris, IRIX, zOS, MacOS, *BSD, iOS, even Android (finally!) are all there, just the hobby OS Linux which is, as always, way behind.

    Perhaps if Torvalds spent less of his time shouting at everyone and more of his time focusing on technical aspects of his abortion of an OS, it might not have this problem.

    1. Doctor Syntax Silver badge

      Re: So basically...

      I suggest you go back up the thread & read thames's posts. You will find that the kernel, you know, the bit that the allegedly shouty Mr Torvalds is responsible for, is now 64bit. The problem is in the userland.

      Changing to 64bit in userland is a bit more of a problem than just recompiling everything with a revised time_t declaration as there may be existing data with the 32bit format which will have to be handled sensibly by the new software. That will be a matter for every application which produces and consumes such data.

    2. LarchOye

      Re: So basically...

      It's not desktop computer systems that we need to worry about for the 2038 shitstorm, it's the multiple millions of legacy embedded systems in everything from satellites in orbit- to that darn stoplight that's ALWAYS turning red right before you get through the intersection...

      Why the fuck such devices should give a shit about the date in the first place- is a valid question, however I don't think it'll be much help in figuring out the scope of disaster we're in for- nor prevent/heal any of it either.

      1. Charles 9

        Re: So basically...

        Any device that doesn't require an absolute date simply needs to be coded to be aware of a rollover and recalculate time differences accordingly. A pretty simple yet sane way to check is if the new time has the high bit nut the old time doesn't (assuming they're signed, the new time is now negative). Unless the device literally has to consider time intervals of over 34 years, it should be safe to assume this is a rollover case, which you can still solve with an adjusted calculation.

        It only gets complicated when a device must know the absolute time for clock or logging purposes AND relies on it being exactly four bytes long for alignment purposes (such as for disk I/O).

  31. -tim
    Alert

    Broken time?

    I had a solaris server wake up in the mid 1800s and its loader wouldn't load shared libraries until the clock was set to something post disco time.

    I haven't been able to replicate the problem since its very hard to tell a Unix system to set the hardware clock to that century and reboot.

  32. Anonymous Coward
    Anonymous Coward

    THIS IS CLEARLY A LIE

    Because Linux is perfect. There's nothing ever wrong with Linux, and it's maintained by trainspotters from their bedrooms, so there.

  33. LarchOye

    SERIOUS PLAN STEP 1:

    Set clocks ahead to 2038, and see what happens...

  34. JamesTQuirk

    I am talking gibberish, as most of you lot are, this article is non-event, as those who take it seriously ...

  35. gcla72
    Joke

    systemd

    systemd will control everything by 2038 therefore this is a non problem.

  36. Captain Boing
    Linux

    <smugmode>

    I have been shouting about this since I was at BT way before 2000 and asking what we were doing about the "Geek's Millennium".

    </smugmode>

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like