• (nodebb)

    To be fair, thousands of bugs got fixed in systems that would have caused loss of life unpatched. I always find it funny then when due to insane effort crisis are averted people start believing there was never a crisis to begin with. It's a pattern that repeats itself over and over again, people really suck when it comes to an objective perspective they are not an expert in.

  • Chris (unregistered)

    "Some systems used a "windowing" solution- every year greater than 50 was assumed to be 19xx, and every year less than that was assumed to be 20xx. This solution sorta kicked the can down the road, and at some point in the future, we might get a Y2K2: Electric Boogaloo as those systems start failing."

    Windows originally picked 2029/1930 as its window. While Windows changed its default to be 2049/1950 recently, other software might not have got the memo, so I would expect some form of apocalypse just 5 years from now.

  • linepro (unregistered)

    Next up 2037 when all the VB / Excel / Access stuff fails..

  • L (unregistered)

    TRWTF is at half the article:

    4-bits would get us 128

  • Krenn (unregistered) in reply to Chris

    Bank mortgages are especially tricky, because home loans are often 30+ years. So right now there are loans that originated before 2000 and others that have a maturity date after 2050. Windowing at 2050 is already starting to be a problem…

  • (nodebb)

    In 1979 I was a young junior programmer at a steel fabrication company. We provided structural steel for buildings, bridges, dams, etc. around the world. Some projects had 20+ year deliveries and our planning and estimating systems ran into the Y2K issue so I was tasked with fixing it. It was an eye-opening experience. When I whined to the greybeards they just laughed and said even if this software is still used in 20 years they will be long gone so I got to clean up their mess. :(

    Throughout the 90s I worked in phone companies. That is a huge globe-spanning machine consisting of millions of CPUs and that's not an exaggeration. We worked hard during that time to find all the ways Y2K could cause problems and fix them. Lots of old systems were replaced and many were fixed. This process improved the overall quality and resilience of the network well beyond the date issue. Even the test equipment in our labs had to be verified as compliant. I had one $50k SS7 tester that ran DOS and could not be made compliant so I had to write a paper on why it would be OK to continue using it.

    It did cost a lot of money but the result speaks for itself. Nothing went wrong. Calls went through, service orders were processed and bills were at least as correct as they ever were. We did this because at that time the company was run by engineers who understood the technology and customers and regulators demanded we not screw up. I have much less confidence in today's corporate management.

  • Brent Seidel (unregistered) in reply to MaxiTB

    Yes! I worked at an aerospace company at the time and was part of a team evaluating their soffware (both the build environment and the aircraft software) to make sure that it would all work properly. I might even still have the shirt buried in a box somewhere.

    If you weren't involved, you don't know how much work was done to ensure that everything worked.

  • (nodebb)

    And, of course, once again, everyone forgets that the Y2K stuff started biting in 1970, when the final payment of new 30-year mortgages started being in ~2000~1900.

    Addendum 2025-01-01 10:44: Bah, whatever the formatting is for strikethrough...

  • Steve (not that one) (unregistered)

    "Airline booking could have been a total shitshow." Uh...

  • (nodebb)

    Oh, and frankly, in my own experience, it started no later than the end of the 1850s.

    No, seriously.

    Somewhen that isn't important, I was researching something that also wasn't important, and in the British Library's Reading Room, I found some forms filled in 1859 by a certain person (who it was isn't important here). They concerned this person's (future) military service, and they were pre-formatted "fill in the blank" forms for a variety of things, but with the year mostly pre-filled as 185___ so that the person filling the form could enter the correct last digit of the year.

    Just a shame that the forms I was reading were filled in ...

    ...

    ...

    1859...

  • (nodebb) in reply to Steve_The_Cynic

    Those types of fill-in dates have been common when you're entering the current date. I remember checks with 19__ fields. Whenever the prefix becomes obsolete you get or print new forms.

  • COBOL Dilettante (unregistered)

    "Well, work, because there are certainly a few still in use." - Working for a major UK high street bank, I smile indulgently at the naïveté of the words "a few"

  • r (unregistered)

    <quote>you also had loads of grifters and con-artists and highly paid consultants.</quote>

    That's a WTF. I mean, when are high-paid consultants NOT grifters and con-artists?

  • (nodebb) in reply to Barry Margolin

    Sure, but it wasn't 19__ (fixed century)... Not at all. They were 185__ - only valid for ten years, not a hundred years. (And the ones I was looking at were filled in in 1859, right at the end of that period.)

  • (nodebb)

    So, obviously, having lived through all that effort to fix such an easily foreseeable problem, we're never going to make the same mistake again.

    If you have a credit card, take a look at it and see how many digits are used to represent the year in the expiry field.

  • (nodebb) in reply to Charles-2

    If you have a credit card, take a look at it and see how many digits are used to represent the year in the expiry field.

    At least there we can use windowing to disambiguate the year, but the point is taken.

  • (nodebb)

    (serious comment, apologies for some naughty words) The current president of Ireland at some point called someone in a debate a "w*nker whipping up fear". As much as there are plenty of good journalists around, the overall feeling I get from the medias (I'm not in the US, so go figure) is exactly the same thing. The pandemic has exacerbated that feeling and it seems that the media outlets (but the social network aren't immune, actually, their algorithms emphasize it), fear is the only driver that "sells".

    There's a gridlocked situation where only fear and exaggerated claims and "clickbait" (which is just the modern way of full width titles back in the newspaper eras or shouted TV) sells, so any other way of providing information won't sell enough, and thus would be buried in the cacophony of people looking into their confirmation biases and thus just drinking and buying into this amount of BS. (There's a page about the "mountain of shit theory" - "teoria della montagna di merda" in the original italian - which explained it also)

    From someone in the field, it's quite a frustrating situation because medias are guilty of not "educating" the public, but actually feeding them misinformation, which then gets easily amplified by the misunderstanding and the likes... (and election results, everywhere, are just one of the perfectly predictable outcome of this).

    (tbh wondering just now, how would Y2K have been with the social networks?)

  • Mark (unregistered)

    All of the dates in the FoxPro 2.5 accounting/compensation database I inherited in 1998 at a small boutique financial consulting form were ten-character "MM/DD/YY" strings... and all of the code manipulating those dates (for billing, timekeeping, and salary/bonuses for bigwigs and minions alike) was ad hoc uncommented spaghetti code.

    When nothing happened on Jan. 1, 2000, I hope at least some nonprofessionals realized it was thanks to people like me wrestling the oily dragon for a year and a half, right down to popping of fireworks and the last commit of 1999.

  • (nodebb)

    I remember it.

    A few months before Y2K, all development work was stopped at my job. All of the developers were then re-tasked with examining every single system and making sure that it would work. This involved setting up duplicate systems, setting the date to 1999-12-31 23:55:00 and then seeing what happened.

    Mostly, nothing happened. The only thing I can remember was file names that had dates in them going from 12-31-00 to 01-01-100, because the C runtime tm struct stored the year as "years since 1900" and people just used that field without modification. Which worked fine, until it didn't.

  • (nodebb)

    It's the IT problem in a nutshell. When IT has things running smoothly, IT has basically nothing to do and thus why do you have all these expensive IT people doing nothing? But when IT has things breaking all the time, IT is running around like a chicken with its head cut off.

    In other words, when things are set up to go right, IT has no work because the work needed to keep things going smoothly is minimal. When things go haywire, IT has too much work fixing what breaks it often cannot spend time doing the things needed to prevent it in the first place.

    Y2K was exactly this. Nothing went wrong because people saw this happening as far back as the 70s (banks were first to notice when they couldn't issue mortgages). But it's also true most people's machines weren't going to explode. However, many business critical servers might malfunction in strange ways that would have disrupted business. Utilities might have been affected - those systems that handle billing might decide you were way behind on your payment and thus your water and power service should've been disconnected years ago. Luckily, those days were way before smart grids with remote disconnects so you actually had to send someone around to shut your water and power, and chances were good that after maybe the first dozen people, someone would have wised up and stopped cutting people's water and power when they realized it was everyone.

    But of course, it's better to not rely on humans being smart enough to recognize when someone is going wrong and not just absentmindedly sending out thousands of "disconnect power" work orders. And who knows, it might happen again when the month rolls around and everyone is still late on bills.

  • (nodebb)

    On the flip side, embedded controllers were a thing, and many needed the time. One thing most programs handle poorly, even today, is time jumps. A discontinuity in time can cause readings and measurements across that period to be off. This is why NTP does what it does and adjusts time slowly so no program should experience the time jump. It's also why gettime() has options like CLOCK_MONOTONIC to ensure the time does not jump unexpectedly because it's extremely difficult to handle them properly.

    And a bad reading in those days might very well cause a cascading failure - perhaps something detects too much power is being sent across a transmission line and it starts by disconnecting loads because the time jumped in a weird way. The grid, as experienced by anyone on the east coast in 2003 or so, doesn't like it when that happens and it can result in a multi-day blackout.,

    A lot of disaster was averted - but that's because we had lots of experience - banks saw it first (25 year mortgages had issues with the date change) and thus the problem was real. Banks also fixed it first (a problem when you have people wanting mortgages you cannot issue) so they had a heads up to what needs fixing. But many new systems in the 90s simply did not handle Y2K very well if at all - even PCs built in 1995 may not have been compliant.

    And maybe those issues were minor - perhaps file dates get corrupted or something, which was fine since time synchronization wasn't a big thing in those days so having PC clocks be hours or days off wasn't unusual, even in a networked environment, so it was at best a minor inconvenience.

    In the end, the big society-ending problems got solved, and the Y2K bug did expose itself when you ended up with a lot of strange dates printed everywhere. Many people wrote cheques and and filled in forms that often had "19__" for the year, proving there were Y2K bugs everywhere.

  • (nodebb)

    The nuclear wars never happened, because ICBMs did not have clocks that cared about date. They had clocks with run times but those started at 0. (There's a famous story about programmers discovering a memory leak in the ICBM software - but since the memory leak would trigger if the program ran more than 2 hours it was not work fixing).

    But it's possible for nuclear reactors to have had issues - not in the reactor blowing up (that usually takes hours), but in the various controllers that control remotely operated valves and such which may end up doing the wrong thing. Though usually in the end the biggest problems were the logs were wrong (activities are highly logged in case anything happens so if disaster happens, things that happened can be figured out, like the black boxes of an aircraft).

    The fact nothing more than minor issues marked Y2K was because of all the efforts done in mitigating its effects - many of which remain classified behind NDAs and other things so the people who knew what really would've happened likely can't talk, have passed, or the documents are sitting away on an obscure server slowly bit-rotting to death.

    Personally, my family had a Y2K issue with their PC - it rolled over and the hardware clock couldn't handle the transition and since it prominently showed the date and time, I wrote a program that fixed it on boot.

  • Some Random Dude (unregistered)

    I think the cost to save (store on disk) the 2 vs 4 digit years on the systems of the 60s and 70s also played a factor. Googling the costs per megagbyte for that era shows costs in the thousands to tens of thousands of dollars.

  • (nodebb) in reply to MaxiTB

    people start believing there was never a crisis to begin with.

    And start questioning whether, or even believing that, the effort was a massive waste of resources.

  • MaryD (unregistered)

    I had an appointment with a doctor on the 29th of February. Their computer thought there was no such day.

  • TheCPUWizard (unregistered)

    Yes and no on the space issue [I started developing in 1972].... once the date was separated from the input record the reserved space did not matter, the date was 6 characters, and a million dates was 6,000,000 characters. This "prune and isolate" [at type of ETL] was quite common. The data file, and the buffer that held a single line (or sometimes a 'burst" of lines) had extra space padding, but the internal data did not. All things relative, Tape was fairly cheer, Disk was quite expensive, but memory was order of magnitude higher.

  • (nodebb)

    Remy, please acknowledge your error

    4-bits would get us 128

  • Hal (unregistered) in reply to Worf

    "Banks started to notice because they could not issue mortgages" right and probably what happen is people did some work and issued and maintained some early 1970 30 years loans the old fashioned way on paper for a few weeks while the COBOL monk(e)s fixed it.

    Y2k was never going to be all that chaotic. For the most part the paper less office had not happened yet. People still new how to run business process with a mixture of hangling files, and Lotus123/Excel which were handling 4 digit years just fine by that point. People were also aware. If the 'over-due-past-180-days' report at the mortgage lender had shown thousands of entries; the humans would have held off calling the local sheriffs to have everyones personal property dragged out to the tree lawns and the locks change, for a few days while the issues were sorted out.

    There would have been problems, lots of problems if we had done less to prepare, and I don't the costs when various interest calculations got settled, assembly line stoppages because JIT deliveries failed to happen, and so on got totaled inaction would have been worse. I also think calamity was never in the cards. Common sense usually does prevail. Nobody was going to walk in to the dairy on 1/2 and "say well the computer says every lot in the place is expired, even the tanks I know I filled on 31st, better just flush it all down the drain anyway!" Delays would have happened product no doubt would have spoiled, but not ALL of it.

    At some point our "data" describes the physical world. Most humans are still (getting sketchier by the year though if you ask me) able to spot when the information the machine is giving them is comically out of step with what is right in front of their eyes. They are also generally settle on some course of action other then self-immolation when faced with a little uncertainty.

  • (nodebb)

    I tend to agree that not everything would have blown up. Things would have been chaotic and I personally wouldn't feel comfortable being on a plane trying to land or takeoff or the like, but most issues would likely have been related to some crazy billing wonkiness. People would get charged far too much, or not charged at all for months/years until someone noticed that there were bills not being paid or the like. But overall - it wouldn't have been catastrophic, just inconvenient.

    At the same time, I think all of the attention and hours thrown at the solution did help make it largely a non-issue when it did happen. The media is always gonna try to ramp things up because FUD sells. Some things haven't changed for decades/centuries. :) But overall - issues didn't happen and people laugh about it because all of this was taken care of before the new year. Yeah, they probably would have been relatively minor had they happened and people would have had a good laugh sometime later, but it was a non-issue for people at least in part because the IT folk made it a non-issue.

  • PERLescence (unregistered)

    I was a pretty new programmer at the time and had written something in PERL 4, which I'd only just learned. The bug that threw me off was that localtime() appeared to return the year as a two-digit one, and I programmed to handle it. Turns out it returns the year as an offset from 1900, so appending 20 as a prefix gave me 20100 for the year; I actually needed 1900 + $year instead.

  • Conradus (unregistered)

    ...And meanwhile, the LA County Sherriff's Department dispatch system is borked because of something baked into their date-handling routines that can't handle 2025.

  • Ken Mitchell (unregistered)

    On January 1, 2000, the only problem that I noticed was that the website for "the inventor of the internet" Al Gore displayed the date as "1/1/19100".

  • COBOL Man (unregistered)

    Back in the day with COBOL on an IBM AS/400, we used a PIC 9(7) COMP-3 field to store dates. This seven-digit compressed field ultimately used four bytes to store a date on disk. We used the first digit to represent the "century", 0 for 1900's and 1 for 2000's. So 1/1/1999 was stored as 0990101; 1/1/2000 was stored as 1000101. We "lucked out" and didn't have to do any mass conversions because all existing dates had a zero as the first of the seven digits. Dates even still sorted naturally as well. Mostly just had to adjust date handling from file to screen/report, screen to file, and when doing date calculations, still a herculean task, but at least didn't have to make file changes and run conversion programs.

    Ahh the good ole' days.

  • Bit01 (unregistered)

    I expected y2k to be a non-event and it was.

    In the sea of bugs that is enterprise software (and which this site also amusingly highlights) one more bug (y2k) is nothing. eg. I don't think I 've ever seen a truly bug free large scale web site; just mouse clicking too quickly is often enough to cause failure.

    As a result everybody, and every business, sensibly already has numerous redundant systems to cover both computer hardware and software failures. And that redundancy means things may be slow but they do work.

  • XennialDev (unregistered)
    Comment held for moderation.
  • Hanzito (unregistered)

    On a side note: don't watch Strange Days, unless you want to waste 2.5 hours of your life on a third-rate thriller.

  • Freeedoom (unregistered)

    Covid19 was a very real problem? Well yeah… if you mean in the sense that it was all a lie you are correct. It was the flu rebranded, meant to spread fear so governments all over the world, in lockstep, could lockdown countries and steal money from the taxpayers. Never in the history of man has so much money been transfered from ordinary people to the billionaries.

    The gross overreaction, not to mention the «vaccines», has done immense damage. It is time for you all to stop believing this lie, but that might mean you have to reasses your entire worldviews, and many people don’t have the mental fortitude to do that… so they continue living in lala-land.

    Now I will just wait for all the personal attacks calling me an anti-vaxxer, conspiracy-theorist and so on.

  • FailedAirlineSurvivor (unregistered)

    You said "Airline booking could have been a total shitshow."

    I worked on Y2K for an airline - one that went out of business not too long after Y2K.

    Their booking system was replaced.

    Their Departure Control System (DCS) was remediated.

    Their frequent flyer system could not be remediated, as they had lost the source code, and although it still retained preferences for their most important frequent flyers, it lost the ability to link their preferences to their bookings after 1 January 2000. Although they knew this in May 1998 - because it was my job to determine what to do, and I had told them, they didn't decide to fix the problem until it was too late. The available resources spent time fixing things like DCS.

    This airline failed for many reasons, but one of them was that the decision makers in the biggest corporate clients finding that they were no longer automatically seated in 1A or 1F as their preferred seat, but 38B because they didn't have their preference linked to their booking anymore, so they moved their entire corporate account to the competitor was one of the reasons they went out of business.

Leave a comment on “Y2K25”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article