161–170 of 385 posts
Airplanes were probably never going to fall out of the sky at the stroke of midnight, but I personally fixed tons of bugs that had potential impacts in the dozens of millions of dollars.
Yes, it was a real potential crisis, and it was only ameliorated because lots of companies spent tons of money testing and reviewing their systems, and fixing bugs that they found. Airplanes were probably never going to fall out of the sky at the stroke of midnight, but I personally fixed tons of bugs that had potential impacts in the dozens of millions of dollars.
Earlier quoted context omitted.
I love these kinds of war stories of incredibly capable people. That was great planning for the unknowns.
I've worked in silicon valley for the past 11 years, in startups as well as two so-called FAANG companies. There are a lot of brilliant people out here. So that is well known. What's not well known is this: there are pockets of brilliant people elsewhere, including Bentonville, Arkansas. Especially in the years running up to 2000, I had the pleasure and honor of working with some of the most talented people in the wo…
Earlier quoted context omitted.
> 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.
That makes a lot more sense, but if it is just input then why not do the conversion of the string "71" to the efficient byte representation of 1971 when it is moved into the storage. If the computer can do a mapping of "71" -> 1971 then why can't it also do a mapping of "10-10-71" -> 26214 (days since 1900-01-01).
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…
This is a good question. I found a copy of Fujitsu COBOL 85 manual [1] (the next release was post y2k, in 2002) and was surprised to see that CURRENT-DATE, INTEGER-OF-DATE use 4-digit years. However some functions from that time (eg ACCEPT, p. 544) do use 2-digit years. I think you have it exactly right, it was about facilitating string formatting/display: ACCEPT took input from the terminal screen. (I think it is, a…
Earlier quoted context omitted.
Really? Even in flyover country the people I know tend to understand that it was only not an issue because of hard work on the front-end.
"Even in flyover country", ouch, you realize the comments earlier about Walmart's Y2K efforts were all driven out of Arkansas, right?
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.
Earlier quoted context omitted.
Really? Even in flyover country the people I know tend to understand that it was only not an issue because of hard work on the front-end.
At least one of us is in a bubble. Whenever it comes up in conversation among general groups, at east half the people are adamant it was all a waste of time and money, and driven my frauds trying to make easy money. Of the remainder, perhaps half don't really have an opinion. The remaining 25% vaguely accept that it was a real problem, but are not at all aware of the real extent. Anecdata, to be sure, but you might w…
Earlier quoted context omitted.
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.
BCD (Binary-coded decimal) comes to mind; which can store values 0-99 in one byte and with native support in older CPUs.
Earlier quoted context omitted.
I've worked in silicon valley for the past 11 years, in startups as well as two so-called FAANG companies. There are a lot of brilliant people out here. So that is well known. What's not well known is this: there are pockets of brilliant people elsewhere, including Bentonville, Arkansas. Especially in the years running up to 2000, I had the pleasure and honor of working with some of the most talented people in the wo…
While I don't have direct knowledge of Bentonville, the general impression that I have formed is that they are one or two cuts above any other enterprise of their size.