Live data from Hacker News

Ask HN: Was the Y2K crisis real?

news.ycombinator.com

61–70 of 385 posts

Re: Ask HN: Was the Y2K crisis real?

#61

Yes, the y2k crisis was real, or more accurately, would have been a serious crisis if people had not rushed and spent lots of money to deal with it ahead of time. In many systems it would have been no big deal if unfixed, but there were a huge number of really important systems that would have been a serious problem had they not been fixed. Part of the challenge was that this was an immovable deadline, often if thing…

Yeah the sheer volume of just bad data entry type situations with messed up dates could have been for some companies absolutely enormous.

Whole businesses would be ground to a halt to stem the mess of bad data and if not prepared they would not have quick fix.

In many cases in the age of apps and web apps we can roll out fixes fairly quickly, but in 2000 that was very much not the case for most situations.

Re: Ask HN: Was the Y2K crisis real?

#62

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.

Re: Ask HN: Was the Y2K crisis real?

#63
post #5

I was working at a telecommunications startup in 1999. They were founded in 1997. A big part of what I was doing was fixing Y2K bugs. That said, none of the bugs would have been critical to the operations of the services. Everything was in the billing systems and I think if unfixed it would have been more of a reputation hit than anything. Also, "begs the question" doesn't mean what you think it means. https://en.wik…

"Begging the question" comes from a centuries-old mistranslation which somehow became a shibboleth. I could probably come up with a dumber way for a phrase to become fixed as "proper usage" but it would take me a while.

Re: Ask HN: Was the Y2K crisis real?

#64

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 enough for us to limp thru and just fix the bad cases by hand as they happened. Eventually we migrated off the whole stack over the next few years so stopped being a problem. I'm sure many mitigation strategies did the same....

Re: Ask HN: Was the Y2K crisis real?

#65
post #54
post #5

I was working at a telecommunications startup in 1999. They were founded in 1997. A big part of what I was doing was fixing Y2K bugs. That said, none of the bugs would have been critical to the operations of the services. Everything was in the billing systems and I think if unfixed it would have been more of a reputation hit than anything. Also, "begs the question" doesn't mean what you think it means. https://en.wik…

I only noticed one manifestation of the Y2K bug myself. I had a credit card receipt that had a date of 1/2/100. Definitely not critical.

Definitely not critical.

To you. But to the store that didn't get any money for thousands of sales and potentially went out of business, definitely critical.

Re: Ask HN: Was the Y2K crisis real?

#67
post #64

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…

This is what I remember a lot of too. While they are little hacks which are imperfect, they bought companies enough time to resolve the issue more thoroughly.

Re: Ask HN: Was the Y2K crisis real?

#68
It was very much real, lots of effort was spent to make sure everything worked correctly, especially around older billing systems which used only 2-digit years in fixed width records.

Because of all the preparation and upgrades being done, I think only incident we had when Y2k migration manager sent out "all clear"-email after rollover - Unix mail client he used formatted date on email as "01/01/19100" - though I suspect he knew of the issue and didn't upgrade on purpose just to make a point.

Re: Ask HN: Was the Y2K crisis real?

#69
post #49

Earlier quoted context omitted.

There's less cause to use small data sizes for timestamps and date codes now. Storage has grown by orders of magnitude, the idea that a numeric data type would only be large enough to store a 2-digit year or that you would want to save disk space by abbreviating an extra 2 letters is foreign to a lot of new developers. And the 20-year-old systems are slowly dissapearing...

More importantly we have figured out algorithms for time that account for timezone, daylight savings time, different calendar systems, and probably something else I'm not aware of. These all work by counting seconds since a fixed date. Note that the algorithms were known since at least the late 1960s. Storage space even then shouldn't have been enough of a concern. However people still screw it up all the time.

And in that vein, no one (sane) is writing their own date libraries anymore, there's no reason to try to customize that for your application.

Re: Ask HN: Was the Y2K crisis real?

#70
post #27

Earlier quoted context omitted.

> I don't know about now but it wouldn't shock me We'll be up for a few Y2K bugs at the start of every decade because 'year += year https://www.pymnts.com/news/payment-methods/2020/new-years-b...

There's less cause to use small data sizes for timestamps and date codes now. Storage has grown by orders of magnitude, the idea that a numeric data type would only be large enough to store a 2-digit year or that you would want to save disk space by abbreviating an extra 2 letters is foreign to a lot of new developers. And the 20-year-old systems are slowly dissapearing...

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 year from 1900-2027.

If you want to store day + month + year with a two digit year you have 365.25*100=36525~ options. A two byte value can store up until 65535 options, which can hold all days until 2079.

If you are storing your dates as flat strings (DD-MM-YY or so) then you are already wasting such a large amount of bytes that "storage concerns" seem moot. You are already using 8 bytes to store a date that can be stored in 2 bytes, at that point why not use 10 bytes?

String formatting and display seems more obviously affected to me than storage.

Post reply on HN