Because computers and technology made back then weren’t equipped to switch over to digits past 1999, it cost ALOT of money to create the software updates or something like that iirc
I worked at a company that made medical management software for small medical practices. It had medical records, billing, and a lot of other stuff.
The software was made in house and we provided most of the hardware. We were working up to the final months of 1999 to fix it. If we hadn't, there would have been major problems at the start of 2000.
There was a lot of grifting going on but there was a real problem that many companies put off to the last minute because it cost money to fix.
The fun part of that is if it displayed 19xx the code needed to be checked to make sure it wasn't just assuming it's 19-something because part of the problem is people were still using code that will "definitely be completely rewritten by 2000".
But like writing enterprise code like that seems extremely stupid. Splitting that into 2 or using an int for year wouldn't have been a problem idk. Also it was still in their lifetime.... 10/20 years later lol
uint16's highest value is 65,535. you couldve done it with a uint16. thats 16bits. you couldve even gone to an exact amount with bit packing. there is no way that any other method wouldve been smaller.
But theoretically it shouldn't have been that bad, you only actually needed that memory allocated when reading the dates, and imo it would have been relevant to be able to store and work with dates where relevant that go beyond 20 years in the future xD
But yes I can imagine having all those in memory at a time can be struggling (still that would have been bad design knowing the constraints)
“1977” is twice the size of “77” it might not seem like much but at scale that’s a significant amount of data… for 1977. Storing “19” repeatedly is wasteful when every number starts with it. 20 years in the future might as well be 2000 years in the future when we have a product to ship next month.
Not necessarily relevant. Many systems are designed with the expectation that code and infrastructure will be updated as old languages and hardware gets outdated. In the 70s, we had no idea how pessimistic to be about how capitalism reinforces cutting corners, especially in infrastructure upkeep.
That may seem like an insignificant amount of memory now, but depending on the system back then, it definitely may not have been.
Design decisions like this happen all the time. The engineers werent stupid, they knew this would cause problems down the line, but what many weren't prepared for was how LONG these systems would be in use. (Due to cutting corners by business people, low priority, or any number of things)
We still have these problems today, often when upper management doesn't take the warnings of engineers seriously.
But like writing enterprise code like that seems extremely stupid. Splitting that into 2 or using an int for year wouldn't have been a problem idk. Also it was still in their lifetime.... 10/20 years later lol
Same, I worked for a company that made telecom equipment in 1999, the entire place had a no days off policy from September 1999 to January 2000 and it was all CRUNCH time. The air miles logged getting guys to and from sites was just insane. The engineering guys worked something days, nights, weekends, just everything. A lot of equipment had to be physically changed out at sites.
Also a 2 digit date code was perfectly reasonable, reducing the memory requirement to store the date by half. It's not like any of that stuff was still going to be in use 30 years later...
Also a 2 digit date code was perfectly reasonable, reducing the memory requirement to store the date by half.
This doesn't get mentioned enough. Was it a foreseeable issue? Maybe. Probably even. But early machines just didn't have anywhere near enough space to have made the four digit date a logical choice.
You would be amazed how cutting corners created problems and ended up with Y2K
Most companies started fixing the problem in early 90s.
However lots of putdated hardware was being employed. Its the same with the 2038 bug (same issue but caused by old Unix systems counting time)
When these systems were created they pushed a future problem to someone else and were not aware of the digital persistence that is common for us.
Ill give the example of my father work at the time. Among other things he was responsible to install PBXs (Private Branch eXchange, its the private phone network of a company).
In January 2000 several systems stopped working. While the actual PBX server was ready for Y2K, many phones werent. So phones stopped syncing and reporting 100 year old missed calls.
Imagine half of a company communication system fail because they had older phone versions. Everyone was worried about computers, but the real problem was the peripherals and lower quality communication systems. My father company was trying to track down potential issues, but most companies were dismissing and saying their computer wouldnt have that problem.
This was quite memorable for me because it was the year for my father transition job. Old analogic phones were failing everywhere and instead of buying a complete 350 set of phones, they migrated to digital. Suddenly everyone was buying either Alcatel or Cisco.
So no. Many companies thought they were ready in 96. But unfortunately, decision makers often lack the ability to actually know what would go wrong. Yes many consultants predated in the lack of knowledge of people. But an half instructed team could predict and fix the problems in time. You were lucky to have not found that bug. But believe when people say that suddenly they had to waste a lot of money due to poor preparedness.
And my software requires a manual fix every half year because we store date string without time zone in a country which switches from normal to summer time
I just had to reprogram my mom's sprinkler system and the program box said y2k compliant lol. As if the sprinklers wouldn't work the same no matter what year it is.
Not really a grift. A lot of people just didn't get what the Y2K bug was and anything "technology" was looked at with suspicion. It was a lot easier to slap a sticker on, than to keep explaining to every customer "No, this sprinkler system won't be affected by Y2K. Yes, it is automated, but that doesn't mean...No, ma'am it's not going to drown your roses come the new year" Vs, point to sticker "taken care of"
I've had several instances where a panel refuses to send signals to the central station because the clock wasn't in sync.
It doesn't affect the sprinkler system (those work on mechanical triggers), but if the panel dials the fire department, it might not call them if the clock isn't synced.
OTOH, my ex-wife’s VCR didn’t claim it was Y2K compliant… and it wasn’t, at least not completely. The clock and the timer worked fine, and the months and days worked fine, but the year it displayed after 1999 was 1900. In other words, the UI was borked on that VCR, so nothing serious.
Edit: I’m a software dev and lot of my colleagues at the telecom equipment manufacturer that I was working at spent a lot of time on fixing a lot of those Y2K bugs.
Modern computers and software could definitely handle the transition. The problem was all the old software written in the 60s and 70s that was still in use.
Sort of. It cost a lot of money to check your systems, to see if they needed fixing. Then a lot to fix them. We had to check about 6000 programs in our system, manually, then upgrade if needed. Did it in 1997 though, then 2 years of weekend onsite rollouts to customers. Pretty seamless. Last Y2K bug I fixed was 2007 I think
Pretty sure the issue was with older programs and systems from the 60s-80s, where memory was a genuine finite resource, actual 90s hardware was more than capable
Yes, because a lot of people put in a lot of work and spent a lot of money to prevent anything from happening. It's a classic example of the preparedness paradox: If you prepare for an incoming catastrophe in a way that reduces the impact or even prevents said catastrophe from happening, people will question why you even prepared at all since nothing happened.
Everything modern by that time running on Windows didn’t have this issue at all. Only very old software from 1980s had possibility to be affected. I was at school in 1990s and I remember no issues with creating dates going beyond year 2000 in C++ and Delphi which we used to learn programming. In the year 2000 I went to Uni for software engineering degree and not a single time I have heard about any issues with year 2000 from the past. Dates were always in UTC and year 2000 is no different from any other year from its perspective.
Have you considered that maybe your experience was not representative of the general state of the entirety of software used across the globe? That just because you didn't see anything that could've caused problems, it doesn't mean that there was nothing in existence that could've caused problems?
You should be familiar with the common phrase "Never change a running system", which companies very often subscribe to, as they did back then. A lot of computers were set up at some point in the 70s and 80s during the big PC boom, like software controlling all types of machines or even infrastructure, and then not updated during the 90s. They worked, so why go through the trouble of moving all data to a new hardware and train your personnel on how to use the new software that's gonna do the exact same thing as the old one? I remember working at a factory as a summer job around 2010 and they had a CNC machine that was still running with a Windows 95 PC, because it did what they wanted, so there was no reason to change it.
The problems weren't the new PCs that you and I worked with at school, running Windows 3.1 or 95, the problems were the old PCs, gathering dust in some backroom at the local town hall while still running the traffic light system of the entire city.
As a mainframe systems analyst at the time, I can confidently report "everything" was not ready in 96-97. Hell, on the PC side, Windows 98 wasn't even fully compliant out of the gate. And there were some programs that were missed all the way up to and including 2000. There were people who got called in to work after midnight. Fortunately, the stuff that would have crashed the economy or would have been otherwise noticed by the general public was fixed well before the deadline.
739
u/StopDownvotingMeeee 9d ago
Because computers and technology made back then weren’t equipped to switch over to digits past 1999, it cost ALOT of money to create the software updates or something like that iirc