back to article Y2K quick-fix crick? 1920s come roaring back after mystery blip at UK's vehicle licensing agency

A mysterious "blip" has caused the printers of the UK Driver and Vehicle Licensing Agency (DVLA) to skip back a century as 2020 rolled round, unless the acknowledgement of a change of keeper took a really long time to arrive. A Register reader, having sold a vehicle, filled out the requisite paperwork and sent it off to the …

  1. MacroRodent


    > with 64-bit time used in the likes of Linux (on 64-bit architectures),

    Work is also progressing on 32-bit kernels and 32-bit compatibility api (see eg. "Approaching the kernel year-2038 end game"), but the problem is the installed base of 32-bit systems that are not going to be updated: Embedded systems, and old servers doing some legacy stuff that nobody dares to touch...

    1. Paul Crawford Silver badge

      Re: 2038

      The simplest 'fix' for 32-bit is to treat the integer as unsigned (but possibly -1 as special error case), that buys you another 68 years. For code that uses dynamic libraries then a fix there ought to fix the program, assuming some coded did not do anything too dumb in re-implementing library time code.

      However, it won't do anything for software on embedded systems as you say, or even legacy 32-bit code that was statically linked and you can't recompile.

      1. A.P. Veening Silver badge

        Re: 2038

        The simplest 'fix' for 32-bit is to treat the integer as unsigned (but possibly -1 as special error case)

        That would require replacing all occurrences of -1 in time tests (but no others whatsoever) with *HiVal. Good luck with editing, compiling and testing. Besides that, it would make it rather difficult to store dates preceding the 01-01-1970.

        1. Paul Crawford Silver badge

          Re: 2038

          No it would not!

          Try it - write a 32-bit program, cast -1 to unsigned and then compare it to -1 and do the same with time_t. You will find they are the same.

          The only catch is if someone has tested a time_t data type along the lines of if(t < 0) instead of if(t == -1) for error handling.

          1. A.P. Veening Silver badge

            Re: 2038

            All programming languages I regularly use as a professional programmer will throw an exception when casting -1 to an unsigned. As for comparisons, those will result in a not equal.

            1. Paul Crawford Silver badge

              Re: 2038


              I have done so in C quite happily for 32-bit code in DOS, Windows (compilers 6.0 and 2018), Linux (32 and 64-bit), and in the past Solaris. And it all works.

              Try this:

              #include <stdint.h>

              #include <stdio.h>

              int main()


              uint32_t uu;

              int32_t ii = -1;

              uu = (unsigned)ii;

              if(ii == uu) printf("test 1 OK\n");

              if(uu == (unsigned)-1) printf("test 2 OK\n");

              return 0;


              $ gcc -Wall itest.c -o itest


              test 1 OK

              test 2 OK

              1. A.P. Veening Silver badge

                Re: 2038

                And C (in all its variations and on all platforms) is a language I rarely if ever use. Try it in RPG or COBOL sometime. And those are just the two best known.

                1. Paul Crawford Silver badge

                  Re: 2038

                  How many Linux systems, or indeed embedded systems are written in those languages?

                  More to the point, all of the system libraries for Linux (the subject of this thread) are written in C so any fix need only work for that.

                  1. Stevie

                    Re: 2038

                    How about perl then? The localtime function is based on a 32-bit library.

                    Good luck diagnosing the sorts of issues that will pop up from that.

                    Why yes, I *have* been there already.

                    1. Paul Crawford Silver badge

                      Re: 2038

                      What seems to be missing here is the original topic - trying to fix 2038 in existing 32-bit Linux programs.

                      The only proper fix (i.e. works as before with signed time_t and works beyond 2038) is to go 64-bit for time_t at least (other integers can be still be 32-bit if you are targeting 32-bit MCUs etc). But that needs a re-compile of the OS and the applications (Perl interpreter in your case). And beyond that it also requires anything that maps time_t in to some structure to accommodate that. Fine for internal memory structures that are re-defined on compile to use 64-bit time_t but no use for code that has time in files, shared memory, etc, so a re-compile for 64-bit is not going to work that easily unless the program already has a debugged 64-bit version.

                      My point was to fix / fudge existing compiled 32-bit code the least-worst option is to make the Linux system libraries treat time_t as unsigned so it runs 1970 to 2106. Yes it breaks pre-1970 date conversion (but that was never defined as working anyway) but there are no better alternatives. Changing the epoch (even dynamically via environment variable per program, etc) will also risk breaking code that has pre-compiled time-points based on 1970, etc. If your machine is running day-to-day, and not working for very old dates, going unsigned for the internal conversion will work well enough. But there will always be something that breaks if you change it, is that any worse than everything breaking post-2038?

            2. Paul Crawford Silver badge

              Re: 2038

              Just to add you can easily include time_t in to the same simple test program. But on typical 64-bit Linux box that is going to fail (as time_t is 64-bit and not the 32-bit unsigned used for this demo) so you need to add 32-bit support for testing it as a 32-bit program. For example:

              sudo apt-get install gcc-multilib g++-multilib

              Then compile for 32-bit machine with:

              gcc -Wall -m32 itest.c -o itest

      2. Dan 55 Silver badge

        Re: 2038

        Not a simple fix, be careful not to trip over backwards-counting for loops and similar, you can't compare the counter against 0 because it could be MAX_INT (-1).

        1. Paul Crawford Silver badge

          Re: 2038

          You rarely count time backwards, and very unlikely for that to be around the epoch of the time scheme. I'm not suggesting making signed integers unsigned, just the treatment of 32-bit time_t

          1. A.P. Veening Silver badge

            Re: 2038

            Just try entering a birth date before 1970, there are still enough of us around.

            1. find users who cut cat tail

              Re: 2038

              time_t is not meant for storing historical dates. If you do that you have much bigger problems than Y2038. You cannot use negative time_t values (they might work, but it is not guaranteed).

              So, what are you talking about?

      3. bombastic bob Silver badge

        Re: 2038

        actually the simplest fix is to make time_t a 64-bit signed integer, and be done with it.

        Then, fix the userland code before 2038 to prevent further problems.

        1. Paul Crawford Silver badge

          Re: 2038

          Bad idea for 32-bit applications in case they store data in fixed size arrays or file-based structure that are assuming 32-bits. For new code the fix is simple - go 64-bit, but for trying to run legacy code beyond 2038 its not as simple a change.

      4. Cynic_999

        Re: 2038

        Erm ... if you treat it as an unsigned integer, then it cannot *have* a value of -1. Maybe treat either zero or 4294967295 as a special case (0xFFFFFFFF)

        1. Paul Crawford Silver badge

          Re: 2038

          That is kind of pedantic as -1 and 0xFFFFFFFF are the same bit-pattern in two's compliment representation for 32-bit variables.

          That is all a compiled program cares about, is the library-returned value equal to this test-case value?

          1. Dan 55 Silver badge

            Re: 2038

            How would you e.g. subtract two times and do a three-way compare if you're using unsigned variables?

            The bit pattern is the same, the meaning to that pattern is given by the data type. It's not easily swapable in a non-trivial program.

      5. Gerhard Mack

        Re: 2038

        "The simplest 'fix' for 32-bit is to treat the integer as unsigned (but possibly -1 as special error case)"

        No! Negative values are for expressing dates before 1 January 1970. Your "fix" would break a lot of software.

        1. Paul Crawford Silver badge

          Re: 2038

          Maybe, but currently most 32-bit Linux time code breaks on negative value

          time_t was never intended for date manipulation (though it ended up that way). Some 32-bit time_t libraries I have tested do work for negative time_t, others are broken (probably as a sanity-check as that is not a supported operation). In most cases what matters for code is getting the current time correctly, and interpreting file time stamps, etc.

          If you need to work pre 1970 and post 2038 there is no simple 32-bit integer solution possible and then you have to make 64-bit changes, recompile, test, etc..

          1. sbt

            Some 32-bit time_t libraries ... do work for negative time_t, others are broken

            (Paraphasing Augustus De Morgan): "Bigger bugs have little bugs upon their backs to bite 'em,

            And little bugs have lesser bugs, and so on ad finitum."

            Mine's the one with the perpetual colander in the packet. -->

          2. Simon Harris

            Re: 2038

            "Some 32-bit time_t libraries I have tested do work for negative time_t"

            ...and would still be useless for representing dates before 1902.

            Negative time_t? My grandma who was born in 1901 would be wrapping around in her grave.

      6. ibmalone

        Re: 2038

        For code that uses dynamic libraries then a fix there ought to fix the program, assuming some coded did not do anything too dumb in re-implementing library time code.

        Surely this depends on quite a lot of factors. If you don't recompile then any variables in your code that were declared time_t will be 32bit and you'll be passing and receiving these 32bit values to and from a library that is treating them as 64bit.

    2. bombastic bob Silver badge

      Re: 2038

      all you really need to do is convert the time_t data type to be a signed 64-bit integer and then fix whatever software bugs happen NOW to deal with it...

      ideally any code using time_t will simply work. And it helps to pay attention to integer truncation warnings, which would be there if you try to assign a 64-bit time_t to a 32-bit integer. THEN you would see it as a compiler warning and HOPEFULLY go "why is that" only to remember that time_t is NOW a 64-bit value.

      Even in 32-bit kernels, you should have support for 64-bit integers... EVERYWHERE.

      As for "other than POSIX" operating systems, let them deal with their own issues. POSIX can simply adapt a time_t that's 64-bit to fix it once and for all.

      1. Dan 55 Silver badge

        Re: 2038

        * Where once and for all is defined to be the 4th of December 292,277,026,596.

        1. Screwed
          Thumb Down

          Re: 2038

          You'll hit the Y10K problem long before then.

    3. Marty McFly Silver badge

      Re: 2038 - I'm outta here!

      Finally a chance to use the coat icon!

      I was a seasoned PFY for Y2K. Fully vested BOFH now. By the time 2038 rolls around, I intend to be sleeping late and laughing at the Millennials struggling through this pile of poo GenX is leaving them.

      1. Bill B

        Re: 2038 - I'm outta here!

        I too am a Y2K veteran. My concern is the pacemaker/mobility scooter/pension payment I’ll be relying on by that point.

    4. vtcodger Silver badge

      Re: 2038

      Work is also progressing on 32-bit kernels and 32-bit compatibility api

      ... and a good thing it is. It's a safe bet that code is being written today that will still be running in 2038 (well the first couple of weeks of 2038 anyway--maybe not after January 18). And furthermore, the simpler, and more forgettable the application, the more likely it is to have a 32 bit time counter. It's unlikely that the Internet will go up in smoke when the 32 bit counters roll over in 2038. And Excel 2037 will, I'm sure, generate innumerable pointless spreadsheets of CFOs far and wide for Feb 2038. But your microwave oven or front door lock may well quit working.

      The sooner toolchains and such even for 16 and 32 bit devices are fixed to work beyond 2038, the better.

  2. Pascal Monett Silver badge

    DVLA's simple solution

    Just modify printer output to start the year with "20" and append the last two digits. That'll buy you 80 years to go and actually do the job right.

    Who am I kidding ? They'll just modify my fix to use "21". Job done.

  3. big_D Silver badge

    Another 20 (18) years...

    That is what we said about Y2K. But the beancounters never listen to the BOFH, so we are stuck with sliding-window problems and we'll definitely have systems barfing in 2038.

    1. Tom 7 Silver badge

      Re: Another 20 (18) years...

      I'd imagine 2038 will be a lot quieter than 2020. Very little Unix/Linux stuff isn't compiled and is thus a lot easier to fix.

      1. big_D Silver badge

        Re: Another 20 (18) years...

        Apart from scripting and interpreted languages...

        But "all" software is compiled, regardless of platform. Your argument doesn't make sense

        And the problem will be the same as the DVLA system, old systems that are no longer supported, where people don't have the source code, don't understand the source code or the system is so delicate that nobody dares touch the code!

        A previous employer wrote Linux based software, but it was proprietary. Up until 2015 they used a version of SUSE Linux Enterprise Server from 2000! In 2015 they couldn't get any more RAID controllers that would work with the SLES drivers, so they were forced to move on, but even so the software was only partially updated and it was still using Qt libraries from the late 90s, because they were too cheap to pay for upgrades.

        Some of the calculations were so complex even the programmers who had been with the company since the beginning were reluctant to change anything!

        Heck, they only turned off their DEC Alpha in 2014, because their last customer had migrated to a SLES server with software from 2000!

        Having access to the source doesn't mean that you have the people or the skills to solve the problem, and having solved the problem, you still have to test everything in combination, to ensure that it doesn't suddenly cause other problems elsewhere.

        If the devices are stuck on an old Kernel and can't be updated, having access to the source isn't going to help, for example. Likewise, if it is a locked down device with no access to the system, even if you can fix the problem, you still need the original supplier to install it for you, if they are even still around.

        The same problem exists with Windows in industry as well. A lot of old industrial hardware has Windows based controllers running Windows 9x or XP, because there is no newer software that will run on a newer version of Windows.

        1. Anonymous Coward
          Anonymous Coward

          Re: Another 20 (18) years...

          DEC Alpha? Sell it to me so I can add it to my horde, I mean collection...

          1. big_D Silver badge

            Re: Another 20 (18) years...

            I hope you have a big basement. It was around 5' wide, 6' deep and nearly 6' high.

      2. A.P. Veening Silver badge

        Re: Another 20 (18) years...

        I'd imagine 2038 will be a lot quieter than 2020. Very little Unix/Linux stuff isn't compiled and is thus a lot easier to fix.

        So what if it is compiled, have you kept the sources?

    2. Warm Braw

      Re: Another 20 (18) years...

      we are stuck with sliding-window problems

      A friend of mine who requested his balance at a cash machine last week saw an effective date in the last century and was unable to withdraw cash. It was hard enough finding people to wrestle with COBOL 20 years ago, so presumably these things will become progressively harder to fix.

      As for the Unix epoch issue, the increasing reliance on random packages from the Internet makes me wonder if in 18 years time there's even any point trying to find and fix the bugs. AI will, in any case, have conditioned us to non-deterministic systems that throw out bizarre results.

    3. G2

      Re: Another 20 (18) years...

      hmmm... beancounters.... BOFH... sliding windows...

      are those real sliding windows for expelling beancounters?


      1. bombastic bob Silver badge

        Re: Another 20 (18) years...

        I can show you, if you step this way...

    4. J.G.Harston Silver badge

      Re: Another 20 (18) years...

      But the problem appears that they *haven't* used a sliding window, they've used a fixed window. If they used a sliding window, the roll-over year would advance a year into the future each year, eg a 2-digit year always resolving to a 4-digit year between 50 years ago and 50 years' time.


      if (year2 > (thisyear+50) MOD 100) year4=((thisyear DIV 100)-1)*100+year2

      else year4=(thisyear DIV 100)*100+year2

      // untested, fails on edge cases

  4. Andy Livingstone

    Even Easier

    Write over it with a pen or pencil. No effort. No brains.

    1. Anonymous Coward
      Anonymous Coward

      Re: Even Easier

      Oh wise sage where has thou gainst your knowledge?

      If the date on the letters is wrong then it's more than likely the dates elsewhere are also wrong in places where they don't print it out.

      1. Rich 11

        Re: Even Easier

        Well if the date doesn't get printed it isn't going to be a problem, is it?

        1. katrinab Silver badge

          Re: Even Easier

          Date: 5th January 1921

          Dear Registered Keeper

          According to our records you do not have a valid road tax for your vehicle. We are now sending our operators round to destroy your vehicle.

          1. J.G.Harston Silver badge

            Re: Even Easier

            Good point, road tax did actually exist back in 1921, before it was abolished in 1935.

      2. Andy Livingstone

        Re: Even Easier

        Look to the right where the 2020 date appears in full glory.

    2. TRT Silver badge

      Re: Even Easier

      19th century solution for a 20th century problem.


      21st century problem.

      1. AMBxx Silver badge

        Re: Even Easier

        If only they'd just printed the year as two digits - problem solved.

        1. A.P. Veening Silver badge

          Re: Even Easier

          How about database storage?

          1. Doctor Syntax Silver badge

            Re: Even Easier

            The irony is that the database storage could be OK and this is just a bodged print conversion. If not the print problem is the least of their worries.

  5. Gomez Adams

    And then there is the 2028 problem on Sperry / Univac / Unisys mainframes as favoured by the US DoD due to the year being stored in a 6 bit field with Year Zero being 1964 - The TDATE$ issue.

    1. Anonymous Coward
      Anonymous Coward

      Re: 2028 problem on Sperry / Univac / Unisys mainframes

      Thanks for bringing it up. I knew there was a problem but haven't done any Unisys work in a bit and didn't remember the year it would go belly up.

      Well they did fix it for the 2200 OS log file. That used an unsigned 72 bit nanoseconds since December 31, 1899,. But at the time we were rewriting all the log file processing to handle the completely new log files (everything changed). We still used the old TDATE$ format to print dates. We could convert the new date/time format to TDATE$ with an Exec supplied library call, but there wasn't any library routines to print the new date out directly.

      We should have made our own code to print the new dates out. Then Unisys wouldn't have had to make up an excuse for why the start date was December 31, 1899 (that's not a typo). Seems someone in the Exec didn't know that 1900 was not a leap year. And no one noticed it till after it was released to customers.

  6. Sgt_Oddball

    Who's a betting man?

    I wonder if there's still be some unrebootrd UNIX system running somewhere when 15:30:08 (UTC) on Sunday the 4th of December, 292,277,026,596 that causes some serious headaches for our BOFH grand9999999thchildren?

    1. TRT Silver badge

      Re: Who's a betting man?

      Here I am, brain the size of a planet and I waited 576,000,003,579 years for your return. A few of those years were spent parking cars. The first 10 million were the worst. Then the second 10 million - they were the worst too. After that I went into a bit overflow...

      1. Chloe Cresswell

        Re: Who's a betting man?

        How's your left side?

        1. iron Silver badge

          Re: Who's a betting man?

          I've a pain in all the diodes down that side.

          1. John G Imrie

            Re: Who's a betting man?

            Do you know, every bit of me has been replaced apart from the diodes in my left side.

  7. Homeboy

    But...but....but that bug thing was just a big money making scam by the evil tech industry wasn't it?

    I read it on the internet, so it must be true.

    1. James Anderson

      Thier were some easily spotted problems that needed fixing. In this case they applied a very simplistic version of the "windowing" solution. The actual recommended algorithm was to check if the twodigit year was less than 20 years from the current two digit year. A bodge which would have worked up till 2079.

      I think the major problem here is that the people writing these systems in the 1970s and 80s never imagined they woul still be running 20 plus years later, and the poor sods patching up the systems in the late 90s never imagined a company would be stupid enough to be running such antiquated systems twenty years later.

      Here I should confess to my own personal Y2K bug. A routine I wrote circa 1988 would follow the 28th February 2000 by another 28th February 2000 .. oops.

      1. A.P. Veening Silver badge

        That isn't the correct date for Groundhog Day.

      2. Baroda

        As a humble coder on COBOL, CICS and the excellent IDEAL with DATACOM/DB back in 1986, we were instructed (no credit to self) to write all date (held as 'CCYYMMDD') manipulation code with the full (4/100/400) checking. All credit to the 2 DB guys and the (business background) IT development manager and 1st class boss. AW, I hope you are alive and well somewhere.

        1. A.P. Veening Silver badge

          And the full 4/100/400 checking can be done with two IFs and one remainder division. And the second IF is only necessary to process the result (leap year or not).

  8. Korev Silver badge

    My work got a bill from a company for >$40billion last week, apparently their software had a 2020 problem. The oddest thing about this is that the supplier was only formed a little over a decade ago...

  9. Doctor Syntax Silver badge

    So these were the systems that were bodged rather than fixed. Remind me again how Y2K wasn't a real problem.

  10. Velv

    Surely this just demonstrates that we have such a lack of ability at fixing the patches that buy us a little time all sensible projects should be coding in five digit years.

    13/01/02020 anyone?

    1. DBH

      As nice an idea as it is, I'd say 64-bit timestamps more than exceed the resiliancy of your solution

    2. katrinab Silver badge

      Anything from 8,000 years ago still around today?

      The oldest institutions I'm aware of are:

      Japanese Royal Household - about 2600 years ago

      City of London - <2000 years ago

      Roman Catholic Church - <2000 years ago.

      Then there's a few companies in Japan from the 700s that are still around.

      1. TRT Silver badge
        1. ibmalone

          7.5 billion years (yes, in some sense, they were here first)

      2. A.P. Veening Silver badge

        The Japanese Imperial Household isn't quite that old. On the other hand, Chinese bureaucracy can be traced back more than 4000 years.

        1. katrinab Silver badge

          The People's Republic of China dates back to 1949.

          1. Richard 12 Silver badge

            Bureaucracy outlives empires

            It outlives everything. Swapping out the top couple of tiers has no real effect.

      3. veti Silver badge

        There are some cave paintings in the south of France, and probably a few other places as well, that are quite a bit older than that.

        Also some archaeological sites, and approximately all fossils.

        But nothing that you would probably describe as "still around", exactly.

  11. BitCoward

    2038? That'll be the least of our worries

    Doctor Who spoiler alert:

    We'll be Orphan 55 ourselves after the Musk rocket gets the 1% off to Planet B.

    1. TRT Silver badge

      Re: 2038? That'll be the least of our worries

      Orphan 55? Sounds like a particularly potent batch of Vodka.

      1. Giles C Silver badge

        Re: 2038? That'll be the least of our worries

        It was a particularly preachy episode, was ok until the climate change threat being pushed to the front.

        1. TRT Silver badge

          Re: 2038? That'll be the least of our worries

          Yeah. Didn't like it. Characterisations were up the creek. Story was bizarre. The young lady in it was seriously gorgeous though. Homicidal terrorist personality kind of puts a damper on that though.

    2. Anonymous Coward
      Anonymous Coward

      Re: 2038? That'll be the least of our worries

      They should call the rocket the Golgafrincham Ark Fleet Ship B.

      1. BitCoward

        Re: 2038? That'll be the least of our worries

        Our Will would call that "a consumation Devoutly to be wished"

    3. Black Betty

      Re: 2038? That'll be the least of our worries

      Nah they'll all be travelling in the B (for billionaire) Ark.

    4. Pascal Monett Silver badge

      Go ahead and get the 1% to Planet B. I'll sit back and LMAO thinking about all those high-flyers who suddenly have to clean up their shit by themselves, just like the rest of us.

      1. John G Imrie

        B Ark

        That's all right, they are taking the phone sanitisers with them

  12. Blackjack Silver badge

    Yeah... sure

    "Still, with almost two decades left before the worst of the problems might show up, there remains plenty of time to fix things. Or to buy that remote cottage on a mountain and start growing your own peas."

    Considering people are still using programs made in BASIC in the public sector and in libraries... Yeah sure.

  13. Loyal Commenter

    And after all, the fix bought another two decades of time – surely beancounters would have stumped up the cost of a proper fix, or systems simply been replaced, by then?

    As with most technical debt, it won't get paid down until it absolutely has to be, no matter whether fixing it properly woudl save money in the long term. The root of this issue is the short-termism of monthly/yearly accounting, and quarterly reporting. Good luck patching capitalism to fix that one.

    1. Doctor Syntax Silver badge

      And ask Travlex if that's really a good idea.

  14. Anonymous Coward


    Being old enough to have gone through Y2K with mainframe COBOL systems, the problem was not that people didn't have the time or money to fix the software, it was that the databases fixes were orders of magnitude more difficult than software fixes. Some sacrificial lamb had to go to the CEO and tell him he needed to shut down all processing for an indeterminate length of time (definitely more than overnight) while all the database records were rewritten to insert "19" in all the date fields. It was not an easy sell for companies with millions of records.

    1. neilo

      Re: Why

      And even that is small potatoes compared to the deeper problem with those databases: record size. A lot of the tables in those systems are close to (or at) their maximum record size. Inserting another 2 characters is simply not possible.

      And even if you could simply insert another two characters, there is an unknown amount of code that parses the records starting at the nth character... all of that code would have to be examined and tested.

      Resizing database columns would be a painful couple of days. Full regression testing of some of these systems? Weeks and weeks.

      1. Doctor Syntax Silver badge

        Re: Why

        A database with a maximum record size even within sight of a feasible row size? Shudder.

        But there's a lesson here for (Fr)agile development. Changing your code may be easy* but changing data is a different matter. If your data is doing the heavy lifting for a business there'll quite quickly be a lot of it and you'd better hope there's a window of time long enough for all your changes.

        There's no substitute for getting the database design good enough to last for a long time and that means up-front design.

        * Relatively depending on how well your automated testing works.

      2. J.G.Harston Silver badge

        Re: Why

        Two bytes is enough to fit 65536 short ints, no need to squeeze two extra characters in, just change the internal interpertation of those two bytes. Instead of year=1900+(byte1 AND 15)*10+(byte2 AND 15) change it to year=byte1+byte2*256

  15. illuminatus


    (insert Brexit gag here)

    1. BitCoward

      Post-Weimar administration parallels ahoy!

  16. Hockney

    Never mind 2038, what about the 22nd century?

    I just want to be here in when Neil and the rest of the Elder Race return to save us from the priests of the Solar Federation.

    They're due some time in 2112.

    1. John Brown (no body) Silver badge

      Re: Never mind 2038, what about the 22nd century?

      "They're due some time in 2112."

      Also a Rush album.

      RIP Neil, you were one of the greats.

  17. SVV

    2025 was also a popular cludge

    So get ready for that one, especially if recently retired. It's possible you might get another annuity.

    I have no sympathy at all for the badly managed disorganisations where managers said things like "Don't bother documenting the fix bcause we haven't got time. We'll sort it out later". Later, of course, meaning never.

  18. Kevin McMurtrie Silver badge


    Has anyone fixed MySQL yet? It seems like all of it's time and time zone bugs are hopeless.

  19. Stoke the atom furnaces


    Moving from 32 to 64bit signed integers only pushes the 2038 problem back to 15:30:08 UTC on Sunday 4th December of the year 292,277,026,596.

    1. Borg.King

      Re: 2038

      Sunday 4th December

      Yay! double the hourly rate then for a Sunday callout.

    2. Imhotep

      Re: 2038

      Coincidentally, I'm on vacation that week.

    3. Anonymous Coward
      Anonymous Coward

      Re: 2038

      Glad it is the afternoon because the plumber is coming around in the morning!

    4. Luiz Abdala

      Re: 2038

      Only Cobol will be running by then. No worries.

      It will be the end of Skynet, though.

  20. Danny Boyd

    A joke I heard 20 years ago

    A COBOL programmer got rich in the end of 20th century, fixing the Y2K bugs in various systems. He decided to spend his money on trip to the future, and bought deep-freeze sleep until the year 100000.

    He awoke, surrounded by people in white gowns, and asked: "Wow, is it year 100000?" One of the doctors said: "No, actually, we had to wake you up earlier. You see, it's year 9999, and we found your CV, it says you know COBOL...?"

  21. sbt
    Paris Hilton

    If I am ever fitted with a pacemaker or medical implant with decades long life-span.

    I'll be asking why the hell it needs to know the date to function.

    Heartstarter. -->

  22. Anonymous Coward

    You're all missing the point!

    The point is that vehicles built before 1979 don't have to pay vehicle tax. So we're all now quids in! Just ask DVLA to send out an updated V5 claiming you've lost yours.

    1. J.G.Harston Silver badge

      Re: You're all missing the point!

      Sorry to come all over Tim Worstall, but cars don't pay tax, people pay tax.

      1. A K Stiles

        Re: You're all missing the point!

        "Sorry to come all over Tim Worstall"


  23. J.G.Harston Silver badge

    Pah! My OS system time doesn't overflow until September 2226.

  24. the Jim bloke

    When everything breaks

    and civilisation crashes into ruins

    people will realise

    it actually was the year of Linux on the Desktop

  25. Anonymous Coward
    Anonymous Coward


    So a lot of coders used 25 as the 19/20 switch. I know because I was told to do this for a largish company I worked at, fixing Mac-Pac on AS/400 on behalf of Andersen Consulting.

    So expect this will happen again somewhere...

    Mac-Pac is still going strong I see....

    1. A.P. Veening Silver badge

      Re: 2025

      On AS/400s you just should use the built-in date type, preferably in ISO format. In about seven thousand years IBM will extend the year with another digit, leaving nearly one thousand years to convert.

      1. A K Stiles

        Re: 2025

        In a previous life where I regularly tangled with RPG and Synon, the AS/400 solution to Y2K ws to add 1 digit to the dates so this esteemed publication was founded in the year beginning 0940101 and the current date is 1200114. As it was an org dealing with mortgages and the like, the window they chose to stick in the code was based around 40, so 39 was converted to 2039, 40 was 1940. I assume they've moved on since then as 2040 is now less than the standard 25 year mortgage term away,

        1. A.P. Veening Silver badge

          Re: 2025

          That wasn't the standard AS/400 solution, that was the standard Synon solution. And I don't know where you live, but here in the Netherlands the standard mortgage term is 30 years.

          1. A K Stiles

            Re: 2025

            In the UK. I arrived amongst RPG / Synon in 2001, just after the poop missed the fan, spent 9 years fixing the subsequent 'minor' issues, writing new stuff and improving various other things, then I changed organisation, before that particular issue became more urgent again.

  26. bartsmit

    Falsehoods programmers believe about time

    This is not the only issue by far:

  27. Anonymous Coward
    Anonymous Coward

    Good practice

    Surely it's good coding practice to allow for events that are beyond the expected lifetime of the software? In the '70s I was setting up a system for quality control logging and stats on a departmental mini in a large multinational tractor company (Skunkworks, to be frank - the mainframe boys were unaware and would have stopped us) where there was no specific date format. So I wrote one in that was Y2k compliant and also recognised 2100 as a non-leap year. No I didn't think it would still be in use then. But good coding practice is a good habit to get into. And the hardware and software was in daily use for another 12 years - does that ever happen now?

    Anon to dodge the agency headhunters - I'm trying to retire from all this...

  28. Anonymous Coward
    Anonymous Coward

    It wasn't that long ago that 2038 was a long time away. Now it's practically next Tuesday.

    How did that happen?

    1. A.P. Veening Silver badge

      How When did that happen?

      While you were sleeping ;)

  29. Luiz Abdala

    I don't even need to go that far...

    I have a CRT television that doesn't have past 2020 in its calendar. It simply wrapped around and started counting from the date of its production - 1990.

    It had a VHS embedded on it, hence it needed a full-blown calendar for recording purposes. Well, the VHS part was already borked 3 years prior, so at least that part was correctly predicted, but the tube was - is - working just fine, with a cable set-top box that still have RCA output, from my cable company. Watching NETFLIX on 4:3 is interesting.

    I found some issues on SOHO routers as well, altough I don't remember which ones... D-Link, I think. Likewise, these wrapped around and kept on chugging, wi-fi and all.

  30. naive

    Sir, we recommend a mortgage with a term of 20 years

    We are already there :-)

  31. Brangdon

    We're now closer to 2038 than to 2000

    We're now closer to 2038 than to 2000.

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