The 'nothing-happened' Y2K bug – how the IT industry worked overtime to save world's computers Forty years ago, both Jerome and Marilyn Murray saw their brainchild reach the light of day. In 1984, their book, Computers in Crisis, was published, becoming the first authoritative guide to the Millennium Bug coding problem, which, in the final year of the century, would consume media, political and business attention. Today …
Did you work for Initech?
Back in the 90s I had an old IBM XT running DOS 3.something and for giggles I set the clock to just before midnight dec 31st '99. It rolled over to 1st Jan :0. It appears no-one had added any code to check for wraparound of the tens digit so it just added 1 to the 9 and moved on up the ascii table.
I was paid £1000 to remotely cover helpdesk for a large financial company that night. There were no calls. The following week it was discovered that an Excel spreadsheet the payroll team used had stopped working but that was the only fallout and it was an easy fix. In this case it was due to careful planning and spending the previous year checking every line of code and updating the database date field lengths. The company spent a lot of money on that project but it worked and what choice did they have? How would investors react to failures when the government warned you about them years before in large public notices.
Personally I regret taking the shift, as it was a lot of money for me back then but I was unable to party as though it were 1999, when it was.
I've already told this (in the linked article) but I'll paste it here for your enjoyment
That fateful night I was on duty, after a year and a half working on that project, for a large bank.
At around 1AM I went to the nearest ATM and checked my balance and latest account movements (not an account from the bank I was working for). There was an interest credit of around the equivalent of 3000€. Resisting the urge to spend it there and then, I went back, showed the slip to my co-workers and pondered on what would happen from there on. At 8 AM, after an uneventful night on the job, I went down and checked my balance again. Without a trace of that earlier payment, it now showed the correct and, unfortunately, much smaller interest deposit...
Someone's night was indeed a lot more eventful than mine ;)
I was unable to party as though it were 1999, when it was
Well, tastes differ. My wife and I were asleep (somewhat fitfully, true, due to a local confluence of idiots and fireworks) at midnight on 1 January 2000, and I do not regret that at all.
A few times I've stayed up for New Year's Eve, only because friends invited me over for a suitably subdued gathering.
Regarding Y2K: those who actually know something about it — which definitely does not include Texas Village Idiot Cornyn — are well aware that there were plenty of important systems which needed remediation. Any number of them were discussed in forums such as RISKS. In late 1999, there was no way of knowing with any confidence how many remained unfixed, or what the consequences might be. Y2K was one of the industry's few shining moments. It's a pity, but not at all surprising, that many people continue to believe otherwise.
Very much the last sentence.
I was involved in a large logistics company's integration testing (so, after systems had been tested individually) and four errors were found that would have stopped suff moving. ATOH, the system pricing insurance damages to cars did not work the first days of 2000, it had reasonably enough not been tested.
I was on call (at ten times my normal rate) for one customer for the two days of the New Year changeover. I didn't get any calls - partly because the software had all been updated and partly because there was no one working at the time. It was a nice little bonus for no effort.
We didn't have any serious problems, only one bit of software that didn't recognise 2000 as being a leap year and got into a loop trying to process data for 2000-02-29.
For laughs I salvaged a Unix system that was being scrapped as non-Y2K compliant to see what it would do. Mostly it was fine. But I did see a few date go from 1999 to 1900, one went from 1999 to 19100 and one went from 99 to A0.
I mean, who’s to know if the “bomb” was ever “live” in the first place. And isn’t it funny how these the “bomb” ‘“disposal”’ “‘“experts”’” are always so quick to arrive whenever a ‘“‘“bomb”’”’ is found... but nothing ever explodes, does it?
Whole thing is a scam. Next time I dig up a WW2 munition, I’m going to give it a good shake and a rap with a hammer. That’ll show them...
"Next time I dig up a WW2 munition, I’m going to give it a good shake and a rap with a hammer."
You (and I) think that's funny - nobody would ever do that, right? Wrong.
A couple of years ago I came home, only to be told that, in my absence, the whole road had been closed, houses evacuated and the bomb squad called after builders digging in a neighbour's garden uncovered a "bomb".
The understandably stunned resident relating the tale told me they'd had chance to speak to the builders while everyone was bundled off to a safe distance.
They told her, "we were digging down and found this.. thing. My mate says 'that's a bomb'. I said it's not, but he says 'it is!!', so I hit it with my shovel a few times. It didn't do nowt, so we called the police."
I have no idea whether it was really a bomb or not, the excitement was over by the time I got home, and nobody, including local media reports, seemed to know for sure. But the prospect of coming home to a smoking crater because a builder hit it with his shovel a few times left me speechless. They really do walk amongst us.
"And isn’t it funny how these the “bomb” ‘“disposal”’ “‘“experts”’” are always so quick to arrive whenever a ‘“‘“bomb”’”’ is found... but nothing ever explodes, does it?"
Not always! Sometimes, there a quite spectacular explosion very close to residences :-)
A fair number of them were over-hyping the risks and making a load of cash out of people who didn't know better. At least one consultancy (Gartner?) estimated a cost to fix that was probably more than the cost of writing all the affected software in the first place. That was surely overblown, since the problem was obvious to anyone writing date-sensitive software at any time since the dawn of computing. My school textbook from the 1980s described the Y2K bug in a discussion of the trade-offs of using a 2-digit date field, noting (correctly) that many applications *already* had to deal with events in the distant past or future.
Notably, my textbook did *not* warn me that 2000 was a leap year and that I should (almost) never bother to implement that silly rule about centuries. Apparently, quite a few people did bother and tripped up on February 29th 2000 as a result. Ironically, they should have been more "agile" (lazy) but I don't think that euphemism had been invented yet.
So what?
There are medical scams; that doesn't mean all doctors are frauds. There are art forgeries; that doesn't mean there are no genuine artworks. There are storm forecasts which turn out to be nothing of significance; that doesn't mean the weather is never bad.
There were plenty of real Y2K bugs that really had to be fixed.
This post has been deleted by its author
logical thought needed to connect all the work done before 2000 with the fact that nothing bad happened at 2000
I'm old enough to have been a Y2K contractor (and, unlike a lot of my colleagues, had actual support and techie experience beforehand). Spent most of my time dealing with non-Microsoft stuff (SunOS/Solaris/HP-UX/GuardianOS on firewalls/etc etc) - mostly because most of my contempories would freak if faced with a command-line and I'd already been using linux for about 4 years (and was a quick learner - this was pre-internet days so it was a case of "sit down with the manuals and learn how to do it")
Did some MS stuff as well and had the particular joy of seeing fully-patched and 'compliant' servers become non-compliant (or differently-compliant) with each successive patch. And applications (which at that point hadn't been patched) crash when the dates offered by the system differed from what they were expecting.
Then the Y2K projects started winding down, releasing lots of badly-trained and inexperienced 'IT engineers' into the contract market and my contract rate dropped and dropped - from £40/hour at one point to £15/hour - at which point it became less financially-viable to be a contractor.
So I blagged my way into a Solaris/NIS/network engineer permie job despite never having done it formally before :-)
The millenium weekend was a great payday for me.
I was paid 1/4 time to stay relatively sober from our shops closing at 4pm on the 31st until they reopened at 9am on the January 3rd, then I was paid quadruple time from the minute I left the house on the morning of New Year's Day, until I got home after checking the computers worked in the four stores in my area.
I don't think I've ever driven so slowly to eke out every minute of that quadruple time...
I had the enviable task of identifying every piece of equipment in the BBC World Service, discovering whether it had a computer/controller in it, and if so, confirming either that it had no date handling or that it could cope with Y2k. Most of it wasn't an issue. But I also had to sort out a couple of HP Unix boxes and it was quickly ascertained that the current OS couldn't handle it, and that the hardware couldn't handle the next OS which could. There were two suitable computers in the country, which we bought; I had to manage getting them to the site (not on the same truck!) and the new OS installed and tested.
That done, I went and spent Y2k new year on Copacabana beach with six million partying Brazilians.
Around Y2K, I worked at a teaching/research hospital. We tested everything. Hardware, software, and embedded systems. One of the systems was a minicomputer system + database which held data on patients' results from experimental drugs. The vendor assured us they had tested the system, and that it was Y2K-compliant.
During our testing, we found that on (simulated) March 1st, 2000, the system deleted the previous month's patient records.
Lying fuckers.
And that's one reason why we tested everything.
We were busy up until the end of December 1999. I had written a lot of stuff that ran under Windows, some of it was not compliant, either because the hardware it ran on wasn't; or because it needed to talk to MS Office components, that weren't. We had a couple of *NIX products that ran on older hardware that were going to fail, so they got moved to Debian on new Intel boxes.
I made the decision to go away to a really nice hotel with no mobile phone coverage on the 30th (just in case). All of our customers were OK, so when I was back at work, I heard a bit of "Nothing happened!" - I reminded them about how much effort and cash was spent over the previous 2 years.
It went a little quiet with our existing customers, but we did mostly bespoke software so we were OK as we picked up new business. A number of the hardware and bog-standard software business suppliers really struggled until ~2003 as "everything was replaced".
As a field engineer at the time, we did basic Y2K testing for the 2 years leading up to 2000 as a freebie whenever we were called out to a fault. But we made VERY clear we were only checking the PCs clock, BIOS and current OS were Y2K compliant and that any software used by the company was their problem to test. It was mainly small companies, many of whom had not even started checking for Y2K yet so at the very least the stickers placed on the PCs was raising awareness (Green for pass Red for fail+notes on the failure type) and at least they knew the computer itself was or was not ready. I don't recall any of our customers mentioning problems in the new year, so I assume they got the rest of their shit sorted out one way or another :-)
Alongside the good work done by techies to ensure that nothing went wrong in system critical/important computer networks and stuff there were another bunch of Y2K people doing very nicely out of unthinking, unnecessary work without any risk assessment..
For us it meant we had to use our meagre budget to have all our work laptops Y2K tested. All of which were standalone machines doing little more than running WORD to write reports and create teaching resources. The worst case scenario would have been that they failed to boot in January- at which point the work could still have been done.
Indeed to save money we hid a few away. A year or so later when we no longer had laptops I needed a basic computer to take with me somewhere - so I grabbed one of these out of its storage- and after charging it worked perfectly. Of course it did. Because the Y2K bug had no relevance to getting it to boot, it wasn't connected to any networks and WORD wasn't affected in any noticeable way.
OTOH sometimes you have to test to be sure - but you only need to test a representative sample if there are multiple similar systems.
It was a few years earlier then Y2K but Sun was reported to find a problem one year turnover which is rather odd given the way Unix kept time.
About the year after that a routine in a system I was looking after started screwing up in January. A boss-written page and a half of C I couldn't understand (not surprising as it was wrong) could no longer decide whether it was being run on a Friday. I replaced it with a one-liner.
Sometime the unexpected happens so testing wasn't wrong.
In general, yes to representative samples, but we tested everything because some motherboards, whilst being visually identical and of the same make/model, had different bloody BIOS revisions and some even had different BIOS manufacturers (AMI vs Pheonix IIRC) so the only way to be sure was to check them all.
And even as recently as 1999, it wasn't unusual for companies to have many different computers bought from various sources over the past 5-10 years. Especially smaller businesses. Large orgs might be able to do a "fleet refresh" across the board, but many if not most SME's would have a mish mash of kit.
That might have been fine in your little shop, but in larger places, it would not have been. That is because in a sufficiently-small shop, "everyone" knows "these" laptops aren't Y2K-compliant, and which, unremediated, should not be used for anything date-sensitive.
At a larger shop, the risk is that not "everyone" knows (or "remembers") that "these" laptops are not Y2K-compliant, and someone finds them in storage, says, "Bonus! I have a project requiring some PCs, and I have no-or-little budget. These unused laptops will work just great!", and emplaces them into date-sensitive usage.
"the Y2K bug had no relevance to getting it to boot"
Yes, but was its date right?
I had a desktop system at home whose BIOS wasn't compliant; after the rollover, it would boot up into 1900. There was no problem setting the running system's date to 2000 -- but I had to, on every boot.
A trivial problem in the grand scheme of things, but still, it showed why it was important not to trust even the hardware.
That box's motherboard was of late '94 / early '95 vintage -- by which point they should have known better.
The HBO movie documentary "Time Bomb Y2K" was released in the UK on 31 December 2023 and used archived footage of the time from interviews, news reports and tv programmes. It was fairly interesting from an historical aspect, but it barely touched on what Y2K was and how people around the world were investigating/fixing it. Instead, it seemed to focus on the naysayers, doom merchants and bunker dwellers - including a few self-proclaimed programmers who stated "I know what's going to happen and I'm going to hide away" - so all in all, it was quite a negative and unbalanced film. Still worth a watch, though, if you have a spare 90 minutes and don't mind an increase in blood pressure every so often when viewing some of the "rational" arguments used by certain participants against the Y2K concept.
On a similar note, my boss and I had an argument a few years back with someone who claimed that Y2K was a big hoax, waste of time and money etc. Oh, and the person we had an argument with worked in IT at the time and by his own admission did Y2K checking. Go figure.
Oh, and the person we had an argument with worked in IT at the time and by his own admission did Y2K checking
A hell of a lot of the Y2K people I worked with were purely script-runners with minimal technical skills.. that relied on the few of us that did have the skills to actually interpret the output and decide what to do.
First time I saw it in anger? 1991(!) 99 months in Duration field is considered permanent (don't ask, just remember the monkeys, bananas and fire hose). Purge process calculated duration in months between start date and now, if greater than Duration, it goes. New Purge, written by ex-colleague calculated the end date as start date + duration......(!) I rang him up at his new company to congratulate him on being the first person to exploit the Y2K bug.
Daftest moment? With Old Father Time breathing down our necks we're in a race to roll out the compliant versions before, er, Y2K. A business unit stalls the entire process by stating that their methodology required a Feasibility Study before any changes and there wasn't one for the new software versions so they wouldn't put it in. We countered with the fact that the 1st of January 2000 wasn't going to move or change so we had had to do it, feasible or not, so we weren't going to waste valuable time on meaningless bollocks. As "get stuffed" trumps wankword bullshit, they fell into line.
Most visible cockup? The US Naval Observatory clock on the web proudly showing the date as 1/1/100. Hooray for ctime. This really cheered up the manager of one of our development teams, who'd been upset to find all their report headers doing the same thing and had asked me to find out why.
As "get stuffed" trumps wankword bullshit, they fell into line
I had the opposite. New Unix boxes replacing two where the application wasn't Y2K compatible.* The pair were replaced by shiny new, acceptance tested and everything. All ready to cut over in the week before Christmas and the New Year. The users - finance - suddenly said no, they weren't taking the risk (hah!) of doing that before they'd closed the year off which would take them until mid-January. We had the vendors dialling in on at least a daily basis fixing errors until we could make the move.
* Actually the version on the old production box was but that on the even older hot standby wasn't. That's the hot standby which wasn't' really that hot as the overnight update had been failing, by running out of time and unnoticed, possibly for a year or more.
I spent numerous weekends in the run up to the end of 1999 walking around the offices I worked in patching the crap out of anything and everything that looked like a computer. Those were the Compaq days, so I walked around with a box of trusty Softpaqs on floppy-disk, running through a set procedure to ensure BIOS, OS, et al, were all ready to go. As I came from an Electronic Engineering background, I said to the IT manager (who had arrived in simlar circumstances to Jen on the IT Crowd) that I would leave the servers and network all running, and deal with any issues on our return in January.
The "clever" people over at the York Street site in Cambridge, decided to power-off their AS/400 - just in case! On our return to the office, I was glad to see everything ticking away as before. We had no issues. The IT Manager receives a phone call from York Street. An announcement will have to be made to all of the AS/400 users on our site stating it will be down for a couple of days. The "clever" people had thrown the breakers, in came a lovely wave of 240 Vac, and the stone-cold power-supplies promptly puked their innards! IBM were, so I heard, run off their feet, as quite a few people around the UK had done the same thing.
At 2000-01-01 I worked for a well-known European telecommunications manufacturer, and I was asked to be alert around midnight (moderate alcohol was allowed). I had to be able to reach the office in 10 minutes on foot, so that was no big deal. A phone company from a neighboring country paid some extra premium for all this. My mobile phone number was assigned to the priority list of my country (phone company was a customer too), to guarantee that I could be reached.
So at midnight I was in the city center in front of the castle, toasting with friends. Like every year, everybody tried to text/call their family, but the network was TITSUP (as happened every year in the pre-smartphone days). Everybody immediately claimed that it must be the Y2K, and looked at me, telling me that we didn't do a good job fixing the problems. At that very moment (00:03 !!), my phone rang, and it was the only one in the crowd that actually worked. Obviously, it worked because I was on the priority list ; a couple of years later I helped to program one myself, and in such a case your call would terminate another random call in progress to make room. "Hey, I work for the phone company" was my defense.
It turned out that it was the customer itself who decided to test our service immediately after midnight, since they paid a good sum for it.
Then obviously everybody used my phone to call their family, since it was the only one that worked for the next 15 minutes or so :-)
I had the same. I worked for a local radio station at the time, and as there was no BBC station in the area, we were part of the emergency broadcast network. As I was the on call engineer, my phone was placed on the priority register.
For several years after 2000 until I changed my provider, I never ever had any problems phoning or texting anyone - never got a network busy notification :)
The mobile base sites treat emergency calls the same way - if the local cell can't service an emergency call, it will drop one of its in-progress calls to allow it to process the emergency call.
It was always the first edge case set of date tests that were dropped if things were running late, given the absolute Y2K date couldn't shift, because everyone's goto mitigation was well we'll have replaced all this tech and be using newer software by then that will fix it for us and promptly erected a someone else's problem field around it.
Maybe just don't book a flight on a commercial plane around that date ;)
When I feel optimistic, I think that, because of Y2K, most systems that deal with dates have been revised shortly before 2000 - a time when 64-bit timestamps were already available. Given that everyone's mind was focused on date problems, a decent amount of those reworks probably switched to 64-bit timestamps directly. The rest were probably decades-old systems already, and many of them are unlikely to have survived 30 more years. It's true that we tend to keep things going way longer than they should, but, even so, a 50-years lifetime can't be too common. Also, system turnaround has gotten somewhat faster; a good bunch of latent 2038 bugs probably got wiped away in shifting to 64-bits architectures.
When I feel pessimistic, I think that, because of the sheer exponential growth of computer systems around the turn of the millennium, and the comparatively limited supply of skilled programmers, there has to be an enormous amount of systems that have been coded by monkeys. Each decade, way more software has been made than the decade before. How much more software has time_t fields, compared to the amount of software that had 2-digit year fields? An order of magnitude more? Two? Even if a pretty large majority of those time_ts were 64-bits, there would still be way more 2038 latent bugs out there than there ever have been Y2K bugs. Also, because of the generally slower turnaround and older architectures, I bet a whole bunch of those are in industrial automation.
Either way, I am slightly worried that nobody seems to be making a serious attempt at figuring out whether there is a problem, and how big it is.
>I wonder how much of a problem the POSIX timestamp overrun is going to be
Potentially much more. Not a lot of embedded systems cared about the year. A lot of control systems care about the difference in two times, a lot of them just use time_t, a lot of them are embedded in places you wouldn't have thought there was a computer and a lot of them are going to be impossible to update.
As others have said, it's likely to be "very interesting" (in the Chinese curse sense of "interesting").
When you're working on a project where the equipment won't actually go into service for "a few years" yet, and then it's expected to be in service for "many" decades, you find there's a lot of dates where things can go wrong. Yes there's the Unix 32bit time rollover, then there's a number of Microsoft date issues, and ...
And you have to think, what if there's a bug in [some item of kit], and it causes every one of them to fail at the same time - that's the sort of thing that gets you checking, and double checking, and then checking again when that's an event that could kill people.
I'll be retired before any of these dates arrive, but it doesn't mean I have the luxury (especially moral) of kicking the problem down the road for someone else to deal with.
This reminds me (again) of hearing the local bowling alley's back office system still ran on a PDP-11 as the millennium approached.
Presumably -maybe I was unofficially told- their solution to existing date rollover problems (while waiting for the upgrade to the Boss scoring system, running under Windows NT) was setting the system date to a year with 1st January on the right day of the week and the right number of 29th Februarys a bit later.
For anybody on ICL 1900 systems Y2K was obviously a non-issue since dates were held as 'days since 31 Dec 1899' in a 24 bit word, so the 1900 rollover date is somewhere around 24881 AD and this kit has always come with a set of standard subroutines for dealing with dates, including converting the 'days since' figure into dd/mm/yyyy and vice versa.
When I started to use UNIX and its relatives and discovered that they stored dates in seconds since 1 Jan 1970 I thought that they'd made a good decision to store dates as seconds and then screwed it up by storing dates in short integers having as few as 16 bits. Still, at least the *nix crowd woke up and switched to a 32 bit time value comfortably before 2038 rolled around.
wasn't available in Gin, which I mainly used
I mainly use gin too - with a nice tonic. Althouygh sometimes it's whisky (without tonic thankyouverymuch - I'm *not* a barbarian).
Sometimes, rum is nice too.
(13 days until January ends. And I can have a nice G&T again. Admittedly, I *did* need a break from alcohol because the 'one G&T' had crept up to 2 G&T then 3 G&T.. and the G wasn't a single either.)
I've always said that the main reason why so many people nowadays think "nothing happened" is because large companies at the time - particularly financial institutions - were very keen to downplay problems when they occurred.
As an example: I clearly remember a national newspaper article in 1999 which highlighted a problem with newly-issued Barclaycards. The problem was exactly what you'd expect: the new cards weren't working because their expiry date was two digits - say, "03" - and the system read that as "1903". A classic Y2K problem, of course, except that when approached by the paper for comment, Barclaycard double-down: it was NOT a "Y2K" problem, they insisted, but an "End of Century" issue...
Nothing to see here: please go away...
I had one so-called expert warn that you needed to air-gap the compliant and non-compliant systems, because otherwise the millenium bug would spread back onto the computers that had already been fixed.
Sure there were some genuine problems that needed to be fixed, but it was mostly doomsday cultists trying to make money from snakeoil fixes.
I was working in the computer time sharing industry - pre PC. I had 2 UK banks doing 25 year country economic forecasts using a product we had called TSAM (Time Series Analysis ?).
In 1975 the 2 banks complained that their forecasts were crashing in TSAM. We realised the problem and it got fixed.
I was stupid by not realising what a gold mine this could be back then in 1975.
I'm to old to bother now but who is getting ready to make money on the 2038 problem. Only 14 years away!
It was complicated... I was confident all the systems I was responsible for stored dates in suitable fields, and the worst I was going to run into were display problems, but there's always the niggling concern: suppose I tell the management there's absolutely nothing to worry about and something comes out of left field. So we did a lot of what turned out to be unnecessary stuff. But you know, it was insurance, and that's the nature of insurance. You pay a lot of premiums and seem to get nothing in return.
Wish I could be around for 1 March 2100. A lot of software got lucky in the fact that 2000 was a century year which was also a leap year because 2000 is evenly divisible by 400 as well as 4. There's an awful lot of software which only tests for year modulo 4 = 0. 2100 will pass that test, but is NOT a leap year.
Perversely, some software got "unlucky" because they bothered to implement the century rule (but ignored the four-century rule).
To be honest, I'm a little surprised that very much software is actually sensitive to this. Don't these people use their system libraries for this sort of task?
I spent all of 1998 doing coding changes and testing on a bank's 1970s-era systems to identify and fix all of the many, many hundreds of 2-digit date fields.
We got it sorted, but this was done in parallel with teams working every night to implement temporary fixes for things that had already broken - the biggest problem was that the banking system was complexly interlinked with an insurance system, and as some of the customers were centenarians, we had birth dates in the 19th century, current dates in the 20th century, and policy expiry dates in the 21st century - all on systems with 2-digit years. It had previously been handled by windowing, but faced with 3 centuries this was breaking down. There were a lot of bodges needed to keep it working until the new date patches could be applied.
Nobody even contemplated replacing the systems - they had tried that previously by getting in IBM to design and trial a replacemenf. It proved to be totally incapable of reconciling accounts overnight in time for the branches to open the next morning. Not entirely a surprise as the original systems were written throughout in highly optimised assembly language and were spectacularly faster than anything coded in higher level languages.
Every now and then I see tales of odd problems in banking systems which sound worryingly like those systems still haven't been replaced.
AC because the less specifics, the better.
Surely back in the 1950s and 60s when a lot of banks were introducing computers for the first time, there would have been a lot of people around who were born in the 19th century. Now, there isn't anyone left who was born in the 19th century, the last one died in 2017, but plenty of people who were born before 1924.
At the company I used to work for I fixed a couple of Y2K Bugs in the software I was responsible for, and our other developers did likewise.
The way we did it was an epic fudge and we just hoped by the time the shit hit the fan none of us would be working there.
Which was lucky, as the company went into liquidation before the fudge went wrong.
Oddly enough, I did some consulting work for an ex-employer some years after I left. I was asked to design a memory module for some huge** inkjet printer, as the then complex 8-layer PCB was too difficult for the remaining engineers. However, this was in 1999 and the then boss asked if I would be willing to conduct a Y2K audit of everything - test gear, production machinery, networks, the lot.
After many days of lucrative but mind-numbing investigations I found just one program that actually couldn't cope with the new millennium. It was an easy fix, but only because I wrote the damn thing fifteen year earlier ...
Yes, they were meant to have replaced it with a commercial offering, but they couldn't find anything that worked as well, so were running my old 16-bit DOS program within Windows. (Clipper anyone?)
Still, it paid well.
Twitched at the mention of Clipper, as one of my first jobs at that company was to replace some crappy Clipper code used for data entry (type in 15 numbers. Make a typo, do the lot again) with something more user friendly.
We did have one piece of code I wrote in about 1994 which I discovered to my horror was still being used by our data department twenty years later. And I'd lost the source code.
The the Great Unwashed would understand the need to prove correctness of software.
As as result of "nothing happened" we have the legal presumption that computer programs (but not humans) are assumed to be innocent until proved guilty. This was apparently one of the factors in the Post Office scandal, AND IS STILL the presumption in English law, I gather.
We also had loony brexiters claiming that "no deal brexit" would be "just like Y2K". Except the analogy would not be a "bug" in the software, but DELETING it altogether at midnight.
>brexiters claiming that "no deal brexit" would be "just like Y2K".
In a way they were right:
1, cause a giant future fsck up by trying to save money in the short term because the long term consequence would be SomebodyElsesProblem
2a, fix the problem by having lots of engineers carefully go over all the places where it might cause problems
or:
2b, ignore the problem and a have a clown spout meaningless drivel while everyone ignores the problem
As I often point out to Y2K naysayers, it's like moving into an old house with really dodgy wiring, paying an electrician to rewire your house, and then later on saying it was a waste of money because your house has never burned down due to an electrical fire.
I worked New Years Eve 1999 through to 2am on New Years Day in the office in my role supporting multiple Mobile Telcos around the world. I think there were 2 of us there. Another in-office shift continued from 2am onwards.
I don't believe there were any significant issues but a *lot* of testing had been performed over the previous 12 months.
Afterwards I went straight to a friend's house party...
I saw this and laughed, but is it actually the root cause?
Had a google to understand. Saw posts of it happening to circa 30 million in Germany but don't remember the news personally.
See no root cause analysis now and the only mention of this being the cause was...
A Reg comment from Boring Bob:
Wednesday 6th January 2010 11:55 GMT
"A definite fail for the programmer." - maybe not
-It is easy to imagine that a programmer decided to avoid the Y2K bug by-.. Did you ever find out for sure?
I remember how fixing the bug used up a large proportion of software developers at the time making it impossible to find anyone to employ. I was working for an American company at the time who closed our R&D office because they kept getting zero replies to adverts in the national press. The Horizon program was developed at the end of the 90's and the bugs in it appear to be due to a lack of skilled programmers. I wondet if the Post Office scandel is a result of the Y2K bug.
Horizon is a direct descendant of ICL Pathway - at the time the most expensive software flop in history
DWP dumped Pathway due to the issues and I'm pretty sure that a large part of Post Office's denial was because they couldn't be seen to have TWO large cockups under their belts
Part of the problem was the experience of small business - who got ripped off by ‘Y2K consultants’. Typically charge a fortune for testing, done, of course by just setting the pc clock to Jan 1st 2000 and then ‘proving EXEL or Lotus 123 worked ok. A lot of those people found out later they’d been ripped off. So to them; yes; Y2K was overblown, over-hyped and never was a problem.
Then you had the idiots in charge - in 1998 I was working for a small company that made encrypting statistical multiplexers (amongst other interesting stuff); because stat mux have clocks the idiot in charge of one client who had several stat max around the world; being Completely Worthless; would not believe that a clock running at 5MHz was not a time/calendar device; but an oscillator (the documentation even said the stat mixes did not use any date/time representation…). After a couple of really frustrating phone calls; I agreed to cary out some Y2K tests. Attach stat max to PC; wind the date forward; and also do leap year compliance test. Document; print out nice shiny Y2K compliant certificates with copy of the test regime. If I remember correctly, my boss stopped me charging £10K - but I did get him to charge £5K; to which the CW idiot in charge refused to believe was the right price because how could we have done the testing so cheaply !
At Y2K itself; I was working for a large global DCS company; had the pleasure of getting a call from somewhere weird in Eastern Australia at 00:05 their time to tell us all in the UK & EMEA that the world had not come to an end. The overtime was well worth it. But an awful lot of the work in the DCS world was placebo work; or proving negatives (this kit does NOT CARE what the date is).
No, not Space:1999
Most building security systems around the world failed to operate on that date unless upgraded in the 6 months beforehand
There was also the Y2038 bug warning shot too - a lot of NTP implementations broke when the top bit of Utime went active and people discovered that treating it as a signed long integer was a bad idea (most of China went offline for 12-16 hours, amongst other things)
3 systems I was tasked with monitoring turned out to have y2k issues - all at law firms with SVR3 unix boxes. A workaround was found and they migrated everything to more modern software/hardware
That would be 9/13/99 in m/d/y format or 13/9/99 in d/m/y format as the date of interest for Space 1999 as October 16, 1997 is for Lost in Space.
California's DMV had a foretaste of the Y2K bug when a 103 year old woman had her driver's license rejected because the DMV software just looked at the last two years of her birth date. IIRC, this occurred about 1970.
I've lost count of the amount of arguments I've had with people over this who say it was a damp squib and a complete hype.
The reason it was a damp squib was the sheer amount of work done to fix it. I worked for a relatively small publisher in London at the time and we still found a number of things that needed fixed.
As a Cobol programmer in the late sixties and early seventies I definitely used the two digit date. It certainly wasn't laziness, I was working on an IBM 360 mainframe with 32K of memory, with the operating system taking 13K. Efficient programming with minimal record sizes was the order of the day, wasting 2 bytes for every occurrence of the date was an obvious saving. And no, the thought of what might happen if my programs were still around in another thirty years or so never crossed my mind.
And no, the thought of what might happen if my programs were still around in another thirty years or so never crossed my mind
In the dim and distant past, when I was pretending to be an IBM mainframe TPF programmer (in the early 1990s) some of the code I was working with had been originally written in the late 1960s. Amongst other things, we were refactoring it to get rid of stuff like self-modifying code (they used every sort of trick to save space! - like reserving 200 bytes in the code segment then building some self-modifying code in it to do branching based on inputs. Not that big a problem when stuff was single-tasking (as long as proper input sanitisation had been done), *big* problem when everything became multi-reentrant).
Most scary? The fiddling with the tape logging code which *had* to be single-tasking so used spin-locks extensively. Mess that up and you have a 'makes-$6-million-an-hour' mainframe spending ages doing a core dump and re-IPL and a *very* unhappy VP of Production Services. I think I did more testing on that change than the sum-total of all my other changes..
I spent more time doing dev support than dev so eventually switched over full time. I *think* the stuff I worked on is probably still around
I worked at the time in fax and copier servicing - we made a fortune by going into a fax machine, settings it's date to 23:59 1999 and checking it moved over to 2000 and still sent/received - drop a Y2K compliant sticker and onto the next one, it was tedious work but paid well - much like PAT testing in the early days.....
Err, a problem with one bit of the article (isn't there supposed to be a "report an error" link ?) :
The Y2K problem stemmed from programmers of systems built in the 1960s, 1970s, and 1980s employing two-digit fields to store the current year – storing 1987, for example, as 87 rather than the full four-digit 1987, either due to memory constraints or perhaps laziness
There's a third, and possibly more common, cause : that the programmers/developers knew and cared, but their manglement refused to allow them to "waste" code space, and/or memory, and/or storage in doing it right.
I remember a lot of work at the ad-agency I was posted to by my MSP employer.
Windows NT Server SP 6a was an update that popped up in late November 1999, much to everyone's annoyance as we were all SP'd on the servers going "well we're all set" after SP6 in October, and suddenly had a whole new round of app testing to perform.
I had been equipped with a rather clunky sat-phone (out of fear that the mobile network would be down) and even then the powers that be decided to have a globally orchestrated shut down on Friday 31st December when everyone SHOULD have been gearing up for the parties, we were shutting everything down globally on a truly giant party call across multiple timezones.
Then of course powering it all up again on Tuesday the 4th (because no-one wanted to work on Monday).
Fun times indeed.
We took the decision - especially in those days of rare zero day exploits and no internet-facing Windows systems - to simply wait till well into the new year to apply 6a. I think it was end of Feb in the end. It helped we weren't experiencing any showstopping bugs that would have required us to apply it asap.
Since my entire IT career came about because I was hired to do sysadmin work while anyone with the slightest dev background was doing fixes in advance of the date, I have to say I've done pretty well out of Y2K too, lo these 26.5 years.
I was employed at IBM at the time and responsible for a number of high profile customers using Global Services. Let's see, 35 Saturdays, 32 all nighters in 1999. It was a non-event because my experience was not unique amongst many others in the profession. Last of the patches went in Christmas weekend.
At the time, IBM wasn't a bad place to work and they had catering in through the morning of the 1st. I was on duty for the rollover for most of Europe through the US.
By the time the next theoretical one comes across (I think it's 2038) I should be retired. I certainly hope so. I have grandkids and maybe great grandkids by then to annoy with my tales of the dark ages before there was this thing called the internet.
I was the on-call for a global company during the year-end week in 1999/2000 and was tasked with checking each region as they passed midnight to see if there was anything they needed assistance with.
When I spoke to our guys in Moscow they told me 'Our Y2K bug has been fixed, our president has been replaced'.
In retrospect, I think that Boris Yeltsin's replacement has proven to be more problematic in the longer term than the millennium bug was!
We ran a NOC in Docklands comprising multiple telephone platforms, exchanges, and such like. We had a big client base at the time routing calls and competing with BT. Good old least cost routing and all that. We'd heard the rumours about pay levels and decided to hold out. Initial offers weren't great. But as it started to get closer the offers improved. We knew we were going to support it - we just wanted to cash in.
So one evening in November we stayed behind late unofficially and put the clocks forward. Everything worked fine and back the clocks went. The holding out continued.
From recollection we were paid treble time New Years Eve, quadruple time New Years day, and a fixed rate bonus to attend. Sixteen of us turned up around 7pm New Year's Eve and worked through to around 4am New Year's day.
The site was rented and had site security. Lots of firework displays were advertised so said security guys escorted us up onto the roof. Twelve stories high with commanding views. We drank champagne whilst watching the fireworks. Couldn't see the Tower Bridge ones due to too much smoke. But the ones at The Millennium dome and the others at Greenwich more than made up for it.
I took loads of photos on my disc camera (15 shots if I remember) then promptly lost it. I still remember the smoke though.
How time flies. Not been up on any roof since. Way too much paperwork these days to do that. Probably wouldn't be allowed due to risk of being hit by fireworks these days. The goggles worn for conker fights would surely be compatible?
Had a few contracts that period, Local Authority, NHS, Shipping, among others.
While the majority of machines, and hardware, were incidentals, and Y2K would have had low to zero impact, I most certainly did uncover many systems which would have had critical failures.
There was no way to identify which systems might be affected without going through all systems - that was certainly expensive, but worth it for the peripheral benefits which corporations did not factor.
What Y2K ended up being was effectively a global stocktake of equipment. It all had to be hunted down, identified, asset tagged, and recorded. I personally unearthed hundreds of thousands of pounds of "awol" equipment - to varying responses.
For a start - human nature being what it is - laptops, and other equipment would suddenly appear in order to be "Y2K proofed" (in some cases personal gear) before walking out the door again. However, that was a fatal error: "Oh, that's where that went to, I've been looking for that" - Asset tagged & logged.
"You know the many, many thousands of pounds of missing equipment the Finance department goes spare over annually? Yeah I found it all, and here's a spreadsheet of where it is, and here is who has it..." Now that went two ways, either a company was delighted, or were horrified. The reason they were horrifed I will leave to the imagination.
Suffice to say at an individual level, I had everything from threats, to tears from employees because their "Freebie Perks" were now company property again. At C-suite level the odd heart failure.
How was it done? Well for the bulk of it, I just dumped a small "Loginfo" script into the network servers which interrogated all Hardware/ Software info from the machines logging in & output the data to a csv.
Then I just exported it into a spreadsheet and set off to find it all - asset tags in hand - the monster that I was! Other than that, I'd be armed with a Finance dept's receipts, and donned my sleuthing hat.
Lax stock-taking, tax write-offs, criminal enterprise - who knew what a tangled web was going to be uncovered....
Even before the end of 1999, trouble was already hitting. I remember reading about a machine at some airport in Norway, I think it was, that automatically issued visas, or travel insurance, or some such, valid for six months. It stopped working in March 1999. Why? Because the programmer had used “9/9/99” as the special value for an invalid date. So guess what happened when real expiry dates looked like that ...
For my own part, I was involved in an effort to automate the DNS registry for the .nz domain from about 1996 or so. A colleague had got hold of some Perl code from the Australian registry, I think it was, for us to adapt to our use. I knew nothing about Perl, but I soon learned. The colleague was quite willing to use only 2 digits for the year, figuring there was no way this bodged-together Perl code (keeping the data for each domain in a separate file, not even using a database) would still be running in 3 years’ time.
I insisted on four-digit years. And guess what: that code stayed in use long enough for another colleague to ask me to submit a Y2K compliance report on it. Which I was quite pleased to send back as essentially “no problem”. (I left out the “I told you so” bit. Because I’m humble, you know.)
And remember, folks, it wasn’t a “millennium bug”, it was a “century bug”. It could happen again, in another, oh, 76 years.
"[...] US senator John Cornyn, who in 2022 took to then-Twitter to speak his brains."
Yes, well, given that he is one of the senators from my state, I can assure you he hasn't much in the way of brains to speak.
"[...] either due to memory constraints or perhaps laziness."
Few seem to remember how expensive data storage used to be or how few developers expected their code to be used for decades.
This post has been deleted by its author
Companies and governments spent billions upgrading code and hardware to head off the Y2K bug... and as the article points out they were largely successful.
But there was something else that no one seems to think about. All those billions were spent on new hardware (or kit to our friends on the other side of the pond). The hardware companies were booming because of all those sales.
Then Y2K came and went, most companies had tons of new equipment, their refresh cycles had gotten totally out of whack so they didn't need to buy new equipment for a while.
Those booming hardware sales collapsed, and in March of 2000, the .com bubble burst.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
