121–130 of 385 posts
We are lucky that the Y2k issue was so understandable by the public. I doubt we will have such luck addressing the Y2038 problem.
Fortunately the two events will occur in the order they that they will. Having a reference will help explain the issue.
I'm seriously thinking of hibernating through the 30 days covering Y2038.
Yes, it was a real crisis. This revisionist history that some are now saying it was no big deal. It was a big deal and many people spent many hours in the 90's assuring that the financial side of every business continued. I am starting to get a bit offended at the discounting of the effort put in by developers around the world. Just because the news didn't understand the actual nature of the crisis (Y2K = primarily f…
It was also a big problem for Medical records as well right? I recall hearing that there was a lot of work around making sure that immunization records and things like that were accurately converted.
He spent New Years in a DC of a big financial firm in NYC. Apparently the firm was so worried about a failure they shelled out big bucks to have UPS maintenance staff onsite during the cut-over "just in case".
Earlier quoted context omitted.
Perhaps you could expand on this as I was not involved in Y2K myself. Storing dates with 2 digit years doesn't seem to make much sense as a storage saving mechanism for me. If you want to store only the year, why not store the years since 1900? That way in a single byte you can go all the way up until 2155. If you want to store it bit-aligned rather than byte-aligned why limit yourself to 00-99? 7 bits can store the…
> why not store the years since 1900 Most input systems were punch cards, which were designed to be fixed-length textual input directly from a user at a card punch machine. Teaching users how to map from “years since 1900” to the correct keys on the card punch is a lot more confusing and error prone than having the computer automatically convert from "71" to 1971.
Just imagine if no one had ever lifted a finger to fix any of the bugs. We only talk about it being a scam because everyone collectively did such a great job mitigating it in time.
In the end you end up in this perverse situation where you have to wait long enough for the public to understand what's at stake but not long enough that you won't be able to keep things under control. Quite the tightrope trick.
Just imagine if no one had ever lifted a finger to fix any of the bugs. We only talk about it being a scam because everyone collectively did such a great job mitigating it in time.
There is a certain class of work in the IT/software world that is utterly thankless - nothing goes wrong and people wonder what they pay you for, something goes wrong and the very same questions get asked.
e.g. "what do we pay all these janitors for when this place looks spotless?"
What does the science say? I have seen exactly zero studies which claim that the y2k bug would have led to disastrous consequences if action had not been taken. Compare that to the CFC situation in the 80's. Scientists agree that the mitigating actions we took saved the ozone layer. Or compare it to the current global warming crisis. Scientists tell us that if we do nothing, we will suffer catastrophic climate change…
From someone who went through it and dealt with code, it was a real problem but I also think it was handled poorly publicly. The issues were known for a long time, but the media hyped it into a frenzy because a few higher profile companies and a lot of government systems had not been updated. In fact, there were still a number of government systems that were monkey patched with date workarounds and not properly fixed…
>dbase At the time I was managing a dBase / FoxPro medical software package...we were a small staff who had to come up with Y2K mitigation on our own. Our problem is we only had source code for "our" part of the chain...other data was being fed into the system from external systems where we had no vendor support. Thus our only conceivable plan was to do the old: If $year It worked in 99.9% of the cases which was enou…
date="200$year"
Earlier quoted context omitted.
When 5MB disk storage system is the size of a small car and costs $50k, you fight for bytes. Or if your data is stored on magnetic tapes and reading in a dataset can be costed by the kilobyte, takes minutes per megabyte, and requires a million dollar's worth of equipment and dedicated staff, you fight for every byte. The phone I carry today is hundreds or thousands of times more powerful than the $5,000,000 mainframe…
If you are fighting for bytes then storing dates as "DD-MM-YY" strings is very inefficient, as you are wasting a factor 4X on storage compared to just storing the days since 1900 as a 2-byte integer. I understand that storage used to be expensive, but I don't understand where the two-digit year comes into play as I can't envision an efficient storage mechanism that is limited to exactly the years 1900-1999.
And the code takes space.
You may think the space is trivial, but I remember working for nearly two weeks on a commercial system to save around 15 bytes on a system, and it was worth it.
Then the culture was embedded ... you worked to save bytes, and didn't do things that would cost more bytes. And the systems worked, and didn't need updated, so they persisted.