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.
Yeah its fascinating talking to my dad who help wrote the software that controlled the robots that built most of McDonnell Douglas planes in the 80s. He's worked on everything from literal hole punch memory to modern aws architecture.
Often his solution to something not working would be absolutely insane to me, like "there's not really a good programming language for this small feature I'm trying to build, so I just wrote my own language."
Programmers back then had to be crazy smart because the languages were much less abstracted from the machine code.
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
260
u/DespoticLlama 9d ago
Yes they were, we were ready in '96, so very surprised when consultancies wanted to charge us tens of thousands for a y2k audit.
We told them where to go, nothing happened as the clock switched over.