Eutelsat OneWeb blames 366th day for 48-hour date disaster
Leap year curse strikes satellite broadband vendor
Networks
6 Jan 2025 | 59
25 years on from Y2K, let's all be glad it happened way back then
Twenty-five years ago on January 1, despite panic and fear that the world was soon to collapse into chaos, nothing much happened. Sure, there were issues that hint at the global catastrophe that the Y2K bug might have been, but most, including The Register rolling over to "year Zero," were worth little more than a chuckle. …
-
-
This post has been deleted by its author
-
Friday 3rd January 2025 05:54 GMT jake
Re: Well, we have 2038 to look forward to
Embedded systems that require accurate dates have been built with 2038 in mind for decades now. The few that survive into 2038 AND are considered vital despite not being date compliant will be replaced, regardless of cost. Most of those bits and bobs will benefit massively from the prior ~50 years of development. Some may even get upgraded, even though on first blush it looks logically, procedurally and financially impossible (see the B-52, for one particularly egregious example).
Anybody developing non-2038 compliant equipment in today's world will get what they deserve ... I run across such things occasionally. Those manufacturers are automatically placed on the permanent unapproved vendor list, marked "clueless management".
-
Friday 3rd January 2025 10:06 GMT phuzz
Re: Well, we have 2038 to look forward to
While I'm pretty sure that (eg) an energy company will have patched/tested any critical systems and will be fine in 2038, I'm less confident that small cheap devices will be; eg the smart meters said electricity company has sent out to all it's customers.
That'll be the big difference; In 2000 the average company probably had a small enough number of computers that they were easily identifiable, and the average home had just one. These days the number of small, cheap, and probably unsupported devices, that have a computer of some sort must be into double figures at least for the average home
-
Friday 3rd January 2025 15:27 GMT LucreLout
Re: Well, we have 2038 to look forward to
While I'm pretty sure that (eg) an energy company will have patched/tested any critical systems and will be fine in 2038, I'm less confident that small cheap devices will be; eg the smart meters said electricity company has sent out to all it's customers.
You make a good point. While many "small cheap devices" would be thoroughly disposable and could just be thrown away with a compliant replacement bought, its the more integrated systems that become a problem. Small cheap computers built into things that aren't small, or cheap.
The main saving grace for Y2K ended up being Gen X arriving as the first generation of professional software engineers, by which I mean we had been taught how everything worked, down to fetch execute cycles, memory, OSI, the lot. So we could see the depth and scale of the problem, fully understand its ramifications, and quickly work to fix it. Contrast that now with a code camped web developer raised on an iPad - the planes would indeed be falling from the sky.
-
Sunday 5th January 2025 10:25 GMT yoganmahew
Re: Well, we have 2038 to look forward to
"Contrast that now with a code camped web developer raised on an iPad - the planes would indeed be falling from the sky."
Well, being one of those gen-Xers who worked on y2k mission critical systems (airline), I can tell you we didn't all know about execution cycles, nor did we need to.
Give the zoomers a break, a tiktoker would explain what they need to do in interpretative dance with a catchy soundtrack from the seventies and they'd all get on a chat and feel their way to a soluton.
-
-
-
Friday 3rd January 2025 23:14 GMT Yet Another Anonymous coward
Re: Well, we have 2038 to look forward to
>Embedded systems that require accurate dates have been built with 2038 in mind for decades now.
It's all the ones that don't require accurate dates, but simply divide some quantity by the difference in time_t from the last measurement - and suddenly decide that your process flow is negative.
There were very few Y2K systems that actually used the year to calculate anything, there are a lot of embedded systems that use time differences.
-
Monday 6th January 2025 19:27 GMT ShameElevator
Re: Well, we have 2038 to look forward to
I’m thinking that some of these “smart meters” could be handled centrally by the backend systems they talk to. Let’s say the the smart meter now reports the date as 01-01-1970, then the central system knows it’s talking to a 3K38-bug system, calculate the correct date and work from that date. This is of cause more of a temporary solution because it can quickly get messy with date calculations and working with summer and either time (if not UTC).
-
-
Saturday 4th January 2025 21:02 GMT John Brown (no body)
Re: Well, we have 2038 to look forward to
"Anybody developing non-2038 compliant equipment in today's world will get what they deserve"
But that was the thing with Y2K. Some of that code was quite literally decades old and still in use. Probably still is today, after patching. There's probably still *nix code running in things that is not 2038 compliant. I'd like to think you are right, and I hope you are right. But I'm getting old and am already jaded, so I'd not like to place a bet on it not being a problem somewhere :-)
-
-
Thursday 2nd January 2025 21:24 GMT sarusa
And for other reasons
I was one of those people, fresh out of college, who fixed at least half a dozen Y2K bugs that would have caused real havoc, like shutting down the US trucking system. Well, the trucks still could have run, but the things that tracked them and told the drivers where they should go now would have fallen over. All that could have been dealt with via pager and landline, but companies were not really set up for a flood of it all at once. Remember, there were 'portable' phones, but truckers certainly couldn't afford them - no iPhones till 2007! So in that case I 'pre-produced' the problem months in advance, testing fake Y2K rollover to existing system and reporting that yes, there is a problem - Ironically, it was not technically the usual Y2K problem, just that the firmware failed to handle Y2K leap years properly (/400 is a leap year!) so it would explode on Feb 29. Then I fixed the firmware, tested that in fake Y2K scenario again, then scheduled an update for the fleets of people using our stuff - that used to be a big deal, you didn't just randomly update untested or even tested stuff whenever you got the urge to take a piss. Then we did it, and everything worked, yay. Repeat that another half dozen times.
But the really big thing was that we all realized and admited there was a problem and we budgeted time and money to fix something IN ADVANCE.
Can you imagine actually doing that now? Nobody ever fixes things in advance. Corporations would just be 'shrug, if it breaks we'll fix it then,' or even 'Yes we know it is totally broken, just ship it anyhow, we'll fix it later,' we see that all the time. You'd have MAGA conspiracy theorists out the ass screaming about how this is a complete hoax because Jesus was born in the year zero so two zero zero zero was part of His Plan or how this was some Fake Woke Problematic thing to inject Jewish Space Laser tracking (or the equiv from the crazy left equivalents). We are being slowly being cooked to death because dumbasses won't admit that CO2, Methane, etc. are thermal insulators, which is some of the most basic possible chemistry. The actual Y2K problem would be trivial now, but as you say, something that was actually of that magnitude would be completely unfixable.
-
-
Monday 6th January 2025 21:33 GMT Terry 6
Re: And for other reasons
That's half the problem. I'd argue that the other half was people taking the piss and fixing stuff that didn't need fixing. None system critical, not connected devices that wouldn't be harmed if the dates were fucked up. For example, stand-alone PCs used for a bit of WP work. Lots of institutions, like schools, paid lots of scarce cash to Y2K proof devices that could have just been left to see if they still worked after the Apocalypse.
Lots of people didn't see the results of Y2K proofing as having saved the world. Instead they saw that the devices which hadn't been updated (because budgets or in private use) worked exactly the same as ones that had.
-
Tuesday 7th January 2025 14:03 GMT CrazyOldCatMan
Re: And for other reasons
Half the problem was that we fixed it so well, most people not in the trade either didn't realise there had been a problem, or insisted that it was all a hoax.
I was EKS [1] during the Y2K stuff and spent a (fairly profitable) 9 months doing Y2K stuff (some Windows but mostly all the non-Windows stuff that the other (mostly minimally-trained) Y2K staff were doing - firewalls, Solaris/HPUX/AIX etc etc))
Did get offered to stay at my last place in the October (they wanted to keep the high-functioning ones on as insurance up until February 2000) but declined as our (EKS) boss was a corrupt piece of scum and his boss (permie) was in on the scamming. Plus, they had *extremely* limited internet access but still wanted us at our desks pretending to look busy for 8 hours a day (in case a senior manager wandered through) so no reading a book/listening to music. I said no. The realised that the EKS market had crashed due to the glut of people coming off Y2K projects and so ended up going permie again. Was a bit of a shock going from £40/h to a regular wage but at least the new post was doing Solaris & Cisco admin (neither of which I'd done before but could blag well enough about in the interview that I got the job..)
Was a good time - one of the contracts was overnight replacement of machines [2] at a major insurance place - we had a fixed number of machines we'd need to do per evening and, because they didn't want to have to pay a permie to do overnight duty with us, we got paid for the whole evening, even if the job didn't take the whole 8 hours allocated. So we'd do the evenings job and then wander off to the local (excellent) curry house.. sadly, 2 months in, they realised that they were way over budget and so released the last 30% of staff, of which I was one :-(
[1] Evil Kontractor Skum
[2] OS/2 Warp (4?) desktops - I was one of the few on the team that had actual experience. Still - the job was just to take the new machines, replicate the D drive using ghost then physically install it on the desk and make sure it booted up.. Little OS/2 knowledge needed.
-
-
Thursday 2nd January 2025 23:14 GMT Doctor Syntax
Re: And for other reasons
"You'd have MAGA conspiracy theorists out the ass screaming about how this is a complete hoax because Jesus was born in the year zero"
Unsurprisingly this makes them numerically ill-informed. The AD/BC dating was devised by a monk called Dionysius Exiguus (Dennis is the English form of the name) who only had Roman numerals to work with and they have no zero nor any concept of zero.
I admit to having been tripped up with this one when writing the program to calculate the dates from 14C dating data. Dates are calculated BP (Before Present) where Present is taken as 1950* when Libby introduced the technique. The standard is a bit arbitrary because for the last century or so increasing amounts of fossil carbon had been added to the atmosphere making it appear older and more recently nuclear weapons testing had added 14C making it younger again. But I digress - having calculated the BP date I then added the AD/BC calculation by simply subtracting 1950.
As we reported dates rounded to to 5 years it didn't really make a noticeable difference. Until I got an Iron Age date that yielded 1950 BP.
* I've been out of that world for a long time now so I've no idea whether they still do that.
-
Friday 3rd January 2025 09:23 GMT nematoad
Re: And for other reasons
Unsurprisingly this makes them numerically ill-informed.
Yes, that really annoyed me at the time as people were celebrating the turn of the millennium a year early. Year1 to year99 does not make a century.
It would seem that the writer is similarly confused as we won't be in the second quarter of the century for another year.
Now let's all kick off the second quarter of the century
-
-
-
Friday 3rd January 2025 18:32 GMT Whiskers
Re: And for other reasons
"I never did get an answer to the question: if decades and centuries start with zero, why don't millenia?"
Oooh, ooh, I think I know this one :))
The answer is, they don't. Centuries start with 1, and so do decades. Think about it; the 20th century had all but one of it's years numbered nineteen hundred and something, it began in 1901 and ended with the year 2000 which gave it it's name. The decades likewise - the first decade ends with the year 10. We are currently in the third millenium of the common calendar, which will end with the year 3000.
Birthdays and anniversaries follow the same logic; your first birthday is one year after your birth.
-
Saturday 4th January 2025 15:17 GMT nematoad
Re: And for other reasons
...it began in 1901 and ended with the year 2000
Argh! No it didn't.
Look, I'm mildly dyscalculic and I can see that 1 to 99 does not make a hundred.
As you partially point out centuries start on year 1 of the century, so the 21st century started on 1st January 2001.
Do get it right.
-
Monday 6th January 2025 22:47 GMT Terry 6
Re: And for other reasons
As you partially point out centuries start on year 1 of the century,
Do they though?
Numbers run 0-9 (even though we tend to count 1-10). A number sequence starts with zero. Our first year starts at age zero and we are one year old at the end of that first year. Our tenth year starts when we reach the age of 9 and we are ten years old when we complete that ninth year and start the tenth.. A century completes after the 99th year. A thousand years when we complete the 999th year.
The first (nominal*) year CE starts at 1st January 0CE and ends at 1 year after the start of counting- which is 1CE. The first century completes at the end of 99 CE. The second century starts at 1st January 100CE
Ditto millennia - the first millennium ended at the end of December 999 and the second millennium started on 1st January 1000
Many years ago when we were young we were able to wind up a friend who'd turned 30 by telling him he was now in his fourth decade. He was, he'd completed three decades and started his fourth.
*Ignoring people playing around with the calendar and all that
-
-
Saturday 4th January 2025 17:09 GMT Doctor Syntax
Re: And for other reasons
They shouldn't. The clue should be in the name. Take the 20th century. Does the 2000 start with 20 (and continue with 00 for 100 which is what century means)? Then it should be in, and the last year of, the 20th century.
Somebody who should have known better, the editor of the 3rd volume of the Wakefield manorial rolls, made the same error in relation to regnal years (the rolls are dated in the form the umpteenth year of Thingummy) so consequently all the dates given have an off-by-one error in the years.
-
-
-
Saturday 4th January 2025 00:28 GMT hh121
Re: And for other reasons
When I was still working on Oracle dbs (in the 90s) and had too much time on my hands, I tried the date arithmetic in Sql for the behaviour around year zero. I found that the year before 1AD is 1BC, it didn't recognise a year zero. Didn't seem important enough to report it though.
-
-
Thursday 2nd January 2025 23:54 GMT Jou (Mxyzptlk)
Re: And for other reasons
Today you would have to make a PROCESS of everything. Due to the higher networking and software count, even without cloud crap, you end up with PROCESS*PROCESS*PROCESS*..... so you'd have to start the "Y2K" stuff ten years ahead...
Once your have your PROCESSes you just have to wait until everything and everyone involved has given their OK, including the cat of the boss who died five years ago (there is a PROCESS for that too) you may be able to run the first test. In your non existing test environment since everyone ignored all emails regarding that.
-
Friday 3rd January 2025 10:26 GMT Anonymous Coward
Re: And for other reasons
I worked for the UK part of a large US aerospace company at the time. The mothership produced a planning document over two inches thick on the processes we all had to follow. We had training courses. We had audits - internal and suppliers. Teams were put together with silo'd responsibilities - manufacturing, accounting, commercial, current products, legacy products, test environments, ......,etc., all overseen by a local IT team which was overseen by a global IT team. The company must have spent millions - possibly on paper alone cos if were in a management position and didn't have the plan on your desk you were looked at askance. In the UK we had people taken off project work do Y2k full time for about 6 months. It was a bit of a nightmare.
In the end the only area in the UK which we identified as potentially problematic were some legacy firmware development environments which had been archived to support safety critical products and we couldn't do anything to them without having to re-evaluate and potentially re-qualify the products, so we took the risk that if we needed to use them after 2000 they'd work or we'd have to use the latest version of the tools and pay the costs of re-qual and new safety cases. Customers were warned and seemed happy that there was something they could put in their Y2k reports - probably just as onerous as ours.
-
Friday 3rd January 2025 14:12 GMT David Hicklin
Re: And for other reasons
> The company must have spent millions - possibly on paper alone cos f were in a management position and didn't have the plan on your desk you were looked at askance.
And that is mostly my memories of the time - filling out audit sheets to say that either the software manufacturer had certified it OK or that we had tested it OK, very little actually needed fixing or kludging i.e if less than 49 = 20xx date otherwise it is a 19xx date
-
Friday 3rd January 2025 19:52 GMT volsano
Re: And for other reasons
A lot of tactical decisions were taken when using the window breakpoint technique.
Should 00-49 = 2000s and 50-99 be 1900s? Or some other year?
If for example, the system dealt with employees' dates of birth, you might have needed 00-34 and 35-99. Or some such.
Of the date-patched systems from 2000 that are still in use, many of them are creeping up to their own unique breakpoint breakdown. And who is left to remember that is coming?
-
-
Saturday 4th January 2025 14:00 GMT munnoch
Re: And for other reasons
It was the same in our shop. The whole place stood still for about 9 months. You couldn't wipe your arse without someone asking if you were Y2K compliant. I'm not aware of anything vaguely serious that was identified by the entire exercise.
The slightly annoying thing for me was that I volunteered a large lump of dead wood from my team for what I thought was going to be a completely dead-end position of local office Y2K manager. The unexpected consequence afterwards was him being catapulted into senior management as a reward for saving the firm from certain doom and based on the mistaken assumption that he now knew how the whole company worked. He didn't. The army of consultants hired in might have. The only silver lining being he found his station in life far removed from anything hands on that he could screw up.
-
Tuesday 7th January 2025 14:08 GMT CrazyOldCatMan
Re: And for other reasons
In the end the only area in the UK which we identified as potentially problematic were some legacy firmware development environments
What amused me was that the Microsoft 'patches' almost always produced time/date bugs - we could apply a patch, run the test suite and certify the result as compliant.
Until the next set of patches - which would produce slightly different results, nullifying the compliance.
-
-
-
Friday 3rd January 2025 06:17 GMT Bebu sa Ware
Re: And for other reasons
Remember, there were 'portable' phones, but truckers certainly couldn't afford them - no iPhones till 2007!
Even before 2000 there were phones roughly equivalent to today's peculiarly named feature phones. In 1999 I had an Ericsson T28 flip phone which wasn't that expensive even in AU where imported electronics were notoriously overpriced at the time.
One reason for the purchase was the move to digital GSM technology which meant I could use the phone on our honeymoon in the Philippines later in the year. (I was having breakfast on the deck of a moored cruise ship in the he Cebu Sea when I received a call from AU asking me to change the toner in a printer - not one of my tasks in any case so doubly funny. ;)
What I do remember was at that time travelling to North America you might require three handsets to access a cellular services while travelling. It was apparently a bit of a dog's breakfast of technologies and frequencies.
This might have been a reason why (long distance) truckers didn't bother with cell phones.
I remember Y2K as mostly a damp squib. There was a lot of nonsense over devices that displayed the year but only ever used the time of day or day of week at most - wall mounted aircon controls were a common example and microwave ovens.
I found more IT things that didn't get the leap year right for 2000 eg SGI Irix 4.0 but obsolete even then.
-
Friday 3rd January 2025 10:16 GMT phuzz
Re: And for other reasons
Up until the mid-2000's, the US seemed to be at least a couple of years behind the rest of the world when it came to mobile phones. At that time Japan seemed to be at least a year ahead of everyone else.
I suspect geography paid a part in that, in population-dense countries like Japan a mobile company could cover a lot of potential subscribers with a relatively small number of cells.
-
Friday 3rd January 2025 14:51 GMT Ol'Peculier
Re: And for other reasons
Absolutely. I had a HTC San Francisco that could play Doom when I went to the US circa 2003 and people were gobsmacked by the power that thing had.
Think I got my first mobile in about 1992, was self employed so pretty much a necessity, Remember putting it in my girlfriends bag when it went off on the tube once and got some really weird looks. How things change...
-
-
-
Tuesday 7th January 2025 14:11 GMT CrazyOldCatMan
Re: And for other reasons
In the end the only area in the UK which we identified as potentially problematic were some legacy firmware development environments
We only got double time (I was a permie by that point) but our manager kept some nice champagne on ice (and paid for the taxis to and from work). And paid for some premium nibbles..
(I learnt a lot from him about how to be a good manager and most of it wasn't material-reward based.)
-
Friday 3rd January 2025 17:01 GMT Andrew Scott
Re: And for other reasons
US truckers probably still going "breaker breaker" on cb in the 90's. Do remember seeing prospective students coming around the corner while on a tour of the campus using cell phones and thinking that these guys are just out of high school using something i couldn't afford with a full time job.
-
Sunday 5th January 2025 19:58 GMT Anonymous Coward
Re: And for other reasons
"What I do remember was at that time travelling to North America you might require three handsets to access a cellular services while travelling. It was apparently a bit of a dog's breakfast of technologies and frequencies."
Yupe, the USA used to have a mix of GSM, TDMA, CDMA, and iDEN operators. There were even some small mobile operators that only covered a single state or even just in the vicinity of a particular city/town with no roaming on to other operators' networks.
I had the "joy" of supporting our product installed at numerous mobile operator customers using these various technologies.
"This might have been a reason why (long distance) truckers didn't bother with cell phones."
Trucking companies in USA tended to use Nextel's iDEN service as it had features such as PTT (push-to-talk) and multi-party calls (as well as data functionality integrated into on-dash displays) and so behaved more like CB radio.
-
-
Sunday 5th January 2025 22:19 GMT ShotFromGuns
Re: And for other reasons
The fact that you can come up with an extremely detailed scenario for MAGA chuds but just toss out "the equivalent on the left" should have been enough for you to admit that there literally IS NO equivalent on the left. I'm so deeply, deeply tired of this reflexive both-sides-ism that automatically tars everybody with the increasingly mainstream Republican brush. Why is it so hard for people to admit that the problems with Democrats and people farther left are nothing whatsoever compared to the absolute insanity and reality denial of the right?
Like, who are you even imagining? The five "Bush did 9/11" conspiracy theorists who still exist somewhere? Stop pretending that there are any meaningful blocs of leftists who turn dangerous lies into actual policy.
-
-
Thursday 2nd January 2025 22:07 GMT Doctor Syntax
"Chances are good that, were we to dig into the postmortem of all those little issues we'd find a lot of IT admins with eggs on their faces for not responding to the need to patch things."
Not the IT admins. My problem was the client's bean-counters who had run UAT successfully on their new Y2K system (the old one wasn't) insisting that they couldn't cut over until they'd finished their year-end routine. We were going to cut over between Xmas & new year; they insisted on mid-January. Nutters.
-
Thursday 2nd January 2025 22:17 GMT DS999
If Y2K had been coming up yesterday
It would have become another partisan political issue, with Trump telling people for years that Y2K is a scam designed to allow Biden to declare martial law and stay in office or something like that. So while the rest of the world prepared the US would be bogged down in political fights over making it happen in the federal government, a third of the states and a small number of big corporations would do nothing, and things would go very badly in some places as a result.
-
-
Friday 3rd January 2025 01:16 GMT Anonymous Coward
Re: If Y2K had been coming up yesterday
God, I WISH.
At work I'm surrounded by MAGA anti-vax chemical contrail nutters that think ChatGPT is the infallible voice of god.
They get their work done and do a good job, sure, but I really wish I didn't have to listen to the bullshit. It's very annoying.
-
Friday 3rd January 2025 06:51 GMT DS999
Re: If Y2K had been coming up yesterday
The guys in the trenches would have done the actual work to prevent Y2K, and were the ones sounding the early calls that something needs to be done. They were the "experts", just like the experts in public health who have been preparing a playbook for a pandemic for years.
But those public health experts couldn't have got anything done without governments willing to put their plan into policy, allocating money to distributing vaccines, minimizing the impact on the economy with support like PPP and stimulus checks, and so forth.
Likewise Y2K in government systems would not have been addressed if those governments hadn't been willing to allocate the money and make it a priority. If the talking heads on cable news had been telling half of them that Y2K is a scam to get cushy government contracts that were actually part of a New World Order conspiracy to install Orwellian surveillance in every computer around the world do you think that money is forthcoming? Do you really believe that no Fortune 500 CEOs who are chummy with those politicians and consume the same news would be skeptical of their underlings' calls for action and refuse to give them a budget to be fully prepared?
Because if you do believe those things you haven't been paying attention the past five years. I mean a sizable chunk of US citizens actually believe covid vaccines contain "5G chips". They certainly weren't told that by people who are "just getting on with it" in the field of public health.
-
-
Friday 3rd January 2025 11:22 GMT Anonymous Coward
Re: Biden's fault
Will be the Standard excuse for however long Trump 2.0 is in power. That could be 2 years or 20 years if he decides for become a real dictator.
He lies about everything. Cue lies about the N'Orleans killer. He wasn't an illegal and Biden didn't let him into the country through an open border.
But being a Vet gives him one more reason to destroy the VA and it will be Biden's fault despite the record saying otherwise. Trump 2.0 will ignore even more facts than before.
Buy those imported things now people. They ain't gonna be cheaper after 20th Jan.
Stockpile food as once all those immigrants are put in camps, no one will be left to pick the crops.
These next 4 years are not going to be nice for anyone apart from Trump as he commands the sinking ship that the US will become from Mar-a-lardo.
-
Saturday 4th January 2025 21:28 GMT John Brown (no body)
Re: Biden's fault
"Stockpile food as once all those immigrants are put in camps, no one will be left to pick the crops."
The "preppers" were right all along? :-)
(Actually, those preppers, unless they managed to keep their bunker totally secret, are just the juiciest targets for whoever has the biggest/most weapons :-))
-
-
Thursday 2nd January 2025 23:33 GMT Spamolot
NYE 2025 caused certain hotel door locks to reset to Jan, 1 1970
Some "unnamed" USA hotel card door lock manufacturer has a Y2K-type problem. Numerous reports started rolling in as 2025 swept across the face of the Land of the Free.
Detailed on this Reddit thread "All our locks died at the stroke of midnight".
-
-
Friday 3rd January 2025 03:56 GMT An_Old_Dog
Paying Us Gazillions
One of the reasons they paid us gazillions was they didn't start their Y2K testing/remediation projects soon enough, due to management-failure. In 1999, I made way more money on just overtime than on my 40 hours/week.
Another reason they paid us gazillions was to create a "due dilligence" defense against potential multi-million dollar lawsuits. (I worked at a hospital/medical research org.)
-
Friday 3rd January 2025 05:15 GMT jake
Re: Paying Us Gazillions
"they didn't start their Y2K testing/remediation projects soon enough"
It was only a current issue in the minds of management. The cold, hard reality is that I and several hundred thousand (a couple million? Dunno.) other computer people worked on "the Y2K problem" for well over 20 years, on and off. Come the morning of January 1st, 2000 damn near everything worked as intended ,,, thus causing brilliant minds to conclude that it was never a problem to begin with, but that's a rant for another day.
HOWever, in the 2 years leading up to 2000, I got paid an awful lot of money re-certifying stuff that I had already certified to be Y2K compliant some 10-20 years earlier. Same for the embedded guys & gals. By the time 2000 came around, most of the hard work was close to a decade in the past ... the re-certification was pure management bullshit, so they could be seen as doing something ... anything! ... useful during the beginning of the dot-bomb bubble bursting.
Look for similar bullshit/misdirection during the end of the first UNIX epoch in 2038 ... despite the fact that all of the important systems that would be affected either already have been, or will soon(ish) be modified, making the so-called problem mostly non-existent. Again.
-
-
Sunday 5th January 2025 02:33 GMT Tim99
Re: an IT community that came together to solve a fundamental problem - LOL
On Y2K night Mrs Tim99 and I stayed in a very nice small hotel without cell phone coverage. We knew that our stuff was OK, and that any potential calls were "Somebody Else's Problem". We were told that a special dinner was offered at $250 a head. So, we went out and bought chips (crisps), biscuits, decent coffee and tea; and then ordered a nice burger and chips from room service (which finished at 6:00PM). We watched the NY as it rolled around the world on TV, just stepping outside to see the local fireworks. The next night a large amount of left-over food was on offer at $30 as many punters had done what we did.
The aftermath was that a lot of the new/smaller IT players left the market in 2001/2/3 because nobody bought any new kit until about 2004. We were fine as we wrote specialist software with little competition. We sometimes include hardware as a "package" if the punter wanted it, but these margins were not large. This might be one reason why a lot of smaller suppliers were selling multiple anti-virus/fixit/memory doubling
scamwaresoftware that *did* have a high margin.
-
-
Friday 3rd January 2025 03:46 GMT An_Old_Dog
Y2K Today
Reasons Y2K today would be worse than the real Y2K was are:
More people > more businesses.
More businesses making computerized things > more businesses making crap-quality computerized things. (Crap-quality factors: non-upgradable firmware; ignorant/indifferent programmers; management-dictated timeframes which nearly-guarantee crap-quality software; and, computerized-thing-maker policy of not providing appropriate [or any -- Patriot, this means you -- updates].
More businesses > more executives buying/mandating purchase of crap-quality computerised things for their business, "Because it is cheaper." (Initially, anyway.)
-
Friday 3rd January 2025 05:26 GMT jake
Re: Y2K Today
The crap quality consumer-ware doesn't matter. It'll die (or whatever), and the landfills around the world will get a trifle fuller. Likewise websites filled with dodgy bespoke code and the like. A few people will scream because they can't twit or face or whatever, but in the long run (two-three days, at most), the screamers will move on to whatever is still working, having forgotten that twit or face or whatever ever existed. Consumers are fickle. They move on to the next thing at the drop of a hat. Small businesses will follow the people.
The real problem is the equipment that allows world-wide communications, same as it was back then. And THAT stuff hasn't really increased in numbers as much as one might think. Raw numbers in bulk equipment, yes ... but the actual bits of code that make it all work? Not so much. There's still only one cellular network in the US, for example, despite it being claimed by myriad individual corporations.
-
Saturday 4th January 2025 21:41 GMT John Brown (no body)
Re: Y2K Today
"The real problem is the equipment that allows world-wide communications,"
I must admit, I was wondering about satellites, in particular the big, long term kit up in geostationary orbit that was conceived decades ago, might have been up there 10 or 30 years and still expected to last beyond 2038. Are there in fact any like that and which may be affected?
-
Monday 6th January 2025 15:44 GMT Spazturtle
Re: Y2K Today
Yes, you just let them roll over and update the ground equipment to compensate.
GPS has rolled over twice now, last time was 5 years ago in 2019, the fix was a firmware update to GPS receivers to be able to correct the date.
OneWeb had a date issue this new year and they had to push out a update to receiving equipment to be able to re-establish comms.
-
-
-
Sunday 5th January 2025 10:31 GMT mike.dee
Re: Y2K Today
There are a lot of devices now that are using complex software using dates and times, and having internet connectivity. A CRT TV set bought in 1995 probably had a microcontroller inside, but all that did was decoding remote signal, and setting registers on various chips. Maybe also was used to manage teletext pages. I still have one of them, and it could display the time, but it's actually displaying the upper right part of teletext pages: with bad analog reception the time became funny characters. If you get a smart TV today there are a lot of applications and it connects alwats to Internet. The software it's way more complex that the one used on a 1995 TV.
The same is for all home appliances that have a smart counterpart. Now probably most of device made now aren't supposed to remain in use in 2038 and electronic devices aren't built anymore for serviceability, but on the other hand the software stack is used could be adapted and somewhat copied on newer devices, so it's possible that the date probles will hide in newer devices, without anyone able to correct the bug, because it's hidden i older and older software cruft.
-
-
Friday 3rd January 2025 08:57 GMT Anonymous Coward
Donned my flak jacket....
"Unfortunately, 69 percent of the IT teams Adaptiva surveyed said that's all but impossible. "
On Windows, yes. Windows is so abhorrent that the company I work for doesn't even use microsoft tools to patch microsoft apps and OS
Android and Apple? Automatic App Store updates and letting users update the OS at their leisure (within 20 days or so)
Yes, we are beholden to the App store Gods, but TestFlight, and Apple's logical and open beta OS programme ensures continuity of service
-
Friday 3rd January 2025 09:47 GMT Dr Paul Taylor
Ariane flight V88
I wasn't at the bitface in Y2K but salute those who were.
The only issue that I saw myself was a few emails dates 19100, probably because Perl's "year" 2000 is 100 not 00.
But in a different context, this unexpected additional character could have caused disaster.
It was a similar trivial thing that was the root cause of the Ariane rocket explosion
-
This post has been deleted by its author
-
-
Friday 3rd January 2025 10:14 GMT volsano
2027
Back in the late 1990s I helped shovel code onto the OK-for-2000 pile for several companies.
One of them had the usual YYMMDD problem in most of its 10 to 20 year old systems. We fixed those.
But it was crucially dependant on several much older systems which had tons of antiquated Assember and used a half-word (16 bit) format for dates. The format was 7 bits for year, 9 bits for day of year.
Their Year Zero was 1900. 7 bits for year brings them up to 2027.
It was decided that fixing a problem that would not occur for nearly 30 years was not a priority.
Was that the right decision!?
I am waiting for the phone to ring in case it wasn't.
-
Friday 3rd January 2025 10:48 GMT katrinab
I was one of the people who was saying "I told you so on 1st January 2000".
Yes, there were some problems. Yes, many more problems were fixed. But lets get real, it was never going to be anything like as bad as the doomsayers were predicting, or, even as bad as the Crowdstrike outage which did actually happen last year.
1: Computers fail all the time. It's a pain, but we deal with it.
2: For most computer systems [using 1990s or earlier technology], having the date set wrong doesn't cause it to fail, and the dates were quite often wrong anyway. Obviously now, with things much more online, security certificate would be identified as being out of date, and that would actually cause catastrophic failure, like what happened to O2 a couple of years ago when they forgot to renew one of their certificates.
3: Most computers actually didn't store dates as 6 character strings. If you want to store them as efficiently as possible, that isn't the way to do it. That's why, for example, lots of computers ended up displaying the date as 1/1/19100, or 1/1/100, which looks a bit silly, but otherwise isn't a problem.
4: In most cases where there is going to be a problem it isn't going to present itself at exactly midnight on 1st January. It is going to be things like a computer thinking that a December invoice that is due next month is 99 years past due, or an invoice isn't due for payment for another 99 years.
-
Friday 3rd January 2025 14:15 GMT A.P. Veening
3: Most computers actually didn't store dates as 6 character strings. If you want to store them as efficiently as possible, that isn't the way to do it. That's why, for example, lots of computers ended up displaying the date as 1/1/19100, or 1/1/100, which looks a bit silly, but otherwise isn't a problem.
A six digit number can be stored in 4 bytes using BCD, already an improvement. The most efficient way to store a six digit date is in two bytes (16 bits) with 7 bits for the year (allowing for 127 years from an arbitrary base zero), 4 bits for the month and 5 bits for the day.
-
-
Saturday 4th January 2025 04:15 GMT IvyKing
1980 was the year zero for DOS, so 2108 will be the problem year for computers still using the DOS date/time format. Tim Paterson did well in encoding date and time into 4 bytes, the time format allotted 5 bits for the hour, 6 bits for the minute and 5 bits for two second chunks. The four byte limitation was from repurposing the 4 bytes used for date on the CP/M File Control Block as one of the goals for QDOS was to make it very easy to port CP/M software to DOS.
There were precursors to the Y2K problem in the form that dates from the 1800's could do goofy things. Back circa 1970, a woman in California was denied a driver's license as the software used by the DMV showed her as being 3 years old instead of 103 years old.
-
Saturday 4th January 2025 05:23 GMT Grunchy
I dunno how many billions of dollars was stolen based on Y2K consulting but if this all comes from one incident of one lady who was 103 years old trying to get a driving license, and being denied because nobody could figure out she wasn't 3 years old, and NOBODY HAS ANY CONFIRMATION OF THAT TALL TALE, then I guess we all learned a very valuable lesson back in year 2000.
-
Sunday 5th January 2025 06:32 GMT IvyKing
You apparently have some problems with reading comprehension.
The incident occurred in the early 1970 if my memory hasn't been garbled by way too much caffeine. The point I was trying to make was that the two digit date format was causing problems WELL BEFORE Jan 1, 2000. As I recall the woman did get her driver's license without too much trouble - an appearance at the DMV was enough to show she wasn't three years old.
-
-
-
-
Friday 3rd January 2025 20:43 GMT headrush
(2) For some values of most...
When I worked at the capacitor factory in the 1990s, one day the computers that controlled the forming baths refused to run the software. Just before they called out an engineer on ludicrous call out money, I discovered that the date on the pc as displayed by DOS was 1970.
I reset it to the correct date and everything ran as expected.
Possibly a flat CMOS battery.
-
-
Friday 3rd January 2025 14:07 GMT Conrad Longmore
There were certainly problems..
There were certainly problems, but well-prepared organisations fixed them quickly - byzantine mainframe applications being a particularly tricky thing.
I think the odd thing was that orgs tended not to 'fess up to problems. The narrative after 2000 rolled in was that *nothing* happened, I think there was some reluctance for orgs to put their hands up and say "well actually we had these issues" because it may have made them look under-prepared. The "nothing happened" narrative rolled on, and now of course there are those who claim there was never a bug to fix..
-
Friday 3rd January 2025 14:36 GMT ShortLegs
I was on eof those who spent months pathcing, upgrading, and replacing non-Y2K compliant systemts with compliant systems, so it wasn't an issue.
Thankfully, we had senior leadership team who recognised that it was a non-event because we had invested in IT to prepare, rather than deciding it had been a non-event all along.
Even the company (FT50, possibly FT2) prior to that had started preparing 4 years previously. In both cases, the upshot was investment in new technology that benefited the respective businesses anyway, regardless of Y2K.
The first (as in above, not chronologicaly) hadnt really done any serious planning; the IT manager was out of his depth despite Y2K and had been given conflicting priorities and then his walking papers. We really started in earnest in Aug 1999! A few hectic months auditing, testing, updating.... one memorable find was a Netware 3.1 server with an uptime measured in years, with the last login circa 1996 (!). I had a team of volunteers all happy to be on standby NYE, and was that confident we were ready I spent NYE in Zurich. Yes, we made a pile of cash in O/T on crash program, and on-call standby payments, but we really did earn them.
-
Saturday 4th January 2025 21:50 GMT John Brown (no body)
"Even the company (FT50, possibly FT2) prior to that had started preparing 4 years previously. In both cases, the upshot was investment in new technology that benefited the respective businesses anyway, regardless of Y2K."
Very large organisations, and most especially those in the financial game, were probably aware of the issue long before 2000 because they are in the long term planning business. Mortgage and even more especially pension maturation dates would have been exceeding year 2000 for decades beforehand.
-
-
Friday 3rd January 2025 17:46 GMT LessWileyCoyote
One of the reasons mainframe assembler programs hadn't been replaced is that they could be significantly faster than the higher-level languages in use in the 90s. A financial org, aware of their Y2K problem, brought in a prestigious consultancy who confidently said they could provide a replacement system. In tests, it was unable to complete the overnight reconciliation process for accounts before the next day branch opening times, something the assembler code managed with time to spare.
The assembler code was rewritten to handle 4-digit years, and for all I know might still be in use now.
-
Tuesday 7th January 2025 14:28 GMT CrazyOldCatMan
The assembler code was rewritten to handle 4-digit years, and for all I know might still be in use now
My first proper job was as a TPF programmer (assembler on big IBM iron) and some of the stuff I was working with had been originally written in the 1960s. And used lots of "clever" optimisations to make the most of every tiny bit of memory and CPU time.
Most of which we had to remove because most of them made the code utterly non-reentrant..
-
-
Friday 3rd January 2025 20:11 GMT Grumpy Fellow
Failed Y2K by sheer laziness
Back in 1999 I was working an embedded project that wasn't due to ship until mid 2000. So on January 1st, 2000 when all the units under development displayed a year of 1900 I just popped in a line that said something like "if (year < 2000) year += 100;" and then went for beer as usual. I guess I should have been proactive and tested it out the day before as a lot of folks were upset that I waited to see if it would fail before fixing it. I guess I'll have to make it +=200; in another 75 years.
-
-
Sunday 5th January 2025 12:00 GMT Dan 55
Re: HOAX
If I wanted to read nonsense like that I'd go to The Guardian where in the great tradition of the press talking about something they don't quite understand they framed it as a debate by the subheading.
-
-
Saturday 4th January 2025 05:35 GMT spold
Not just that....
I worked with other institutions at the time (perhaps related to the Italian government), where the introduction of the Euro was perhaps greater and more urgent/scary ... where there were lots of programs with currencies that included the Italian Lira (a fraction of a tuppence) that meant that Cobol etc. legacy program values (perhaps millions of lines of code) that defined them as large integers (and the coders/documentation left 20 years ago so go work it out) suddenly required a decimal point (0.!) ....BTW Icon because it it is still the "Holidays" for some of us.
-
Sunday 5th January 2025 20:51 GMT Anonymous Coward
Re: Not just that....
In the 2000s Turkey introduced the New Turkish Lira (YTL) by stripping six zeros off the Turkish Lira (TL), so 1 YTL = 1,000,000 TL. However there was an overlap period where both types of notes were in circulation at the same time. I assume this may have introduced some IT systems complications.
-
Monday 6th January 2025 11:47 GMT Ken Moorhouse
Re: New Turkish Lira (YTL)
Which reminds me. I wonder how many systems out there can cope with hyperinflation. This will be where we find out if systems use "lossless" number formats, and if they have thought properly about boundary conditions. On another note, I'm sure there were inconsistencies when UK made changes to their VAT rate after a long period of stability, particularly with regard to transactions that straddle the point at which VAT is accounted for by different traders.
-
-
-
Saturday 4th January 2025 14:14 GMT Downeaster
Another Way to Solve the Y2K Problem
I remember from a news report, a nuclear power plant set their computer clocks ahead to 1-1-2000 just to see what would happen in 1999. Their system shut down. So they came up with a unique solution. They set the computer clocks on their control computers to a year that was date compatible with 2000. I believed they set the the clock back to 1987. The new two digit year of 87 solved the problem, kept the dates compatible with 2000, and life and power generation went on. This happened I believe in Russia. Innovation is the mother of invention I guess! :)!
-
Saturday 4th January 2025 16:16 GMT heyrick
My Y2K story
I was working as a Care Assistant (like an auxiliary) in a nursing home. Come the afternoon of the 31st myself and a bouncy Dutch girl spend most of the time not looking after the
inmatesresidents, but instead trudge up and down stairs unloading obscene amounts of bottled water, batteries, cheap torches, and tinned tomatoes (I shit you not) into the attic. Well, it's like two and a half times the normal weekend rate which was less than some agency workers were getting but more than the Dutch girl (being own staff, she was on straight weekend/holiday rate).My shift eventually finished so I went home. And back to work on January 1st after the world failed to implode.
I rather imagine most, if not all, of that crap is still up in the attic. Assuming, that is, that the residents weren't kicked out and the place torn doesn't to build "luxury accommodation". I've seen that happen too.
-
Saturday 4th January 2025 19:44 GMT Blackjack
[When Y2K hit, there was no AWS, no online streaming services, smartphones, or social media: Sure, we had the internet, but the world was nowhere nearly as constantly online as in 2025.]
I miss those days, even if my Internet connection was really slow, I used Dial Up until the year 2004.
Also The year 2038 problem will probably catch up down the pants in some things.
-
Sunday 5th January 2025 12:49 GMT Ken Moorhouse
I'm glad that most here valued our efforts...
I did my fair share of Y2K consultancy.
I admit to it having to pay off some technical debt though. I knew for a fact that there would be big problems on 1/1/2000 if appropriate action was not taken.
When I worked on London Underground's computerisation of the Northern/Victoria lines (way before the millennium) we had a problem that the computers being used didn't have the oomph to manage all the tests needed to perform some of the required processes. On at least one program I worked on (to do with programme machines: see google) there were several tests that needed to be repeated on demand every couple of seconds. If the processing of those tests (manifested as inter-process messages in the system) took longer than the allowed time then the message system would collapse (with a negative queue count error: for those of you familiar with GEC 4XXX architecture), taking the whole system irretrievably down with it. It was like a snowball effect, which could be set off by a completely unrelated process taking slightly longer to run. Among the discussions we had to resolve the issue was my suggestion to treat 1/1/2000 as a "special value", which meant that one comparison would suffice for at least two purposes. It doesn't sound like much of an optimisation, but it made a lot of difference in performance. I had already asked what the expected lifetime of the project would be and was reassured that the system would be upgraded well before 2000.
An example of another kludge we had to do in the original system we worked on was also to do with programme machines. IIRC there was not enough space in core to deal with the total number of these on-site, so special code was created to deal with those situated at Kennington (there were an inordinate number located there, compared to other locations). I was totally unaware of this code until I was tasked with taking on and upgrading the program for a replacement system. The performance was dogged by these special tests so I asked if there was any other reason for treating Kennington in this way. The answer was nope so we took up more core to make all programme machines act in a more homogenous way, and performance improved.
-
Sunday 5th January 2025 20:02 GMT gcarter
Night Shift
I remember the roll over to 2000 Anno Domini with some miff
Was annoyed with our neighbours ripping off fireworks at midnight, because I was in bed trying to sleep before my 2am shift started!
Yeah yeah, it was the start of a new day, week, month, year, decade, century, millennium but come on guys, am trying to sleep!
The company I was working for at the time, distributed data for the oil and gas industry, and part of my job was to wait for reports and stuff arriving from North Sea oil rigs at specific times during the night.
A quick conversion to PDF, flinging my expertly curated 'portable document format' into a custom built Lotus Notes database, mash the replicate button and job done!
I recall feeling quite smug when everything worked as expected and rolling my eyes at all the fuss the company made to the build up.
The thing which pleased me the most about that shift, was my Casio Databank watch had rolled over to the year 2000 without a hitch.
-
Monday 6th January 2025 07:52 GMT omikl
Y2K and all that
I saw in NYE 2000 standing in a customer's IT department, to be on hand just in case things went titsup.
Another customer had their bespoke pension system completely redeveloped to make it Y2K compliant, as the old one had been cobbled together in house using COBOL and duct tape some time in the late '80's.
When the UAT was underway for the replacement system, which involved running the old & new systems in parallel through the month end payment cycle, it highlighted discrepancies between the old and new systems. The new one was paying out more pensions.
Why?
Because some pensions were being paid to the surviving spouses of people born in the 19th Century, and the old code had decided that they weren't due to be paid a pension yet as it was getting the date maths wrong, and had been for who knows how long... I wasn't on the apps team so I don't know the details.
What I do know is that some of the OS features that were made available to facilitate Y2K testing, such as virtual date zones, would come in bloody useful right now.
-
Monday 6th January 2025 14:43 GMT Martin Gregorie
I'm surprised that nobody has mentioned that ICL 1900 and 2900 kit was immune to the Y2K bug
...unless some idiot system analyst had specified a date as ddmmyy in reports or file specifications.
This is because all 1900 and 2900 systems store dates in 24 bit words as 'days since 1900', so their 'Y2K' date is around 26,000 AD. Standard software libraries contain a set of date manipulation subroutines for translating dates between binary and character string representation and for manipulating binary dates. The 1900 and 2900 COBOL compilers were re-issued to handle 4-digit years in ample time to avoid data Y2K problems: the only problems I remember seeing were connected with payrolls that dealt with (a few) people born in the late 19th century.
BTW, I note in passing that some of the older IBM COBOL compilers for their smaller machines wouldn't ACCEPT 4 digit years until several months after 1 Jan 2000.
Biting the hand that feeds IT
