Live data from Hacker News

Ask HN: Was the Y2K crisis real?

news.ycombinator.com

101–110 of 385 posts

Re: Ask HN: Was the Y2K crisis real?

#101

No. It was not. I was a software developer in a large US Bank at the time. We had already dealt with it years ago for critical systems. All the banks had.

It was a VERY widely held belief by the general public that Y2K only applied to real time clocks and wall time.

However arguably most dates in corporate IT work are involved in some level of forecasting and prediction and future planning.

In reality, starting in 1970 anyone writing an amortization table program for a 30 year mortgage had to work around Y2K. Anyone dealing in any way with the expiration date for a twenty year term life insurance policy had to start caring about Y2K in 1980. Even a mere net-30 business to business payment account either broke or not in nov-1999. Even on Dec 31 1999 it was hilariously charming how people all around the world thought all computers were located in THEIR timezone and thus any real time clock type failures would occur at precisely midnight local time where they live as opposed to where the computer is actually located. Due to the miracle of UTC time anything bad would have happened to our stuff early in the day while I was eating a late dinner, not when the operations center overstaffed during local timezone 3rd shift.

I was working at a telco at the time and we were very worried and overstaffed over Y2K, our stuff was fine, but we were pretty worried about rioters and such if anyone ELSE failed, like maybe the power co. Hilariously the power co people were probably overstaffed over Y2K, despite knowing their stuff was fine, they were likely worried about those telco goofballs failing thus losing SCADA links to their substations, LOL.

In the end it seems pretty much nothing failed anywhere, as I recall. Or the failure rate for that day, was no higher than any other average calendar date.

Re: Ask HN: Was the Y2K crisis real?

#102

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...

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.

Re: Ask HN: Was the Y2K crisis real?

#103

To add a little nuance: A global retailer you've definitely heard of that used to own stores in Germany spent a lot of time preparing for Y2K. This was a long and painful process, but it got done in time. But problems still slipped through. These problems ended up not being that big and visible because a large percentage of the code base had just been recently vetted, and a useful minority of that had been recently u…

>> This was immediately noticed ..., a fix was ... rolled out in less than an hour.

I guess Agile/Scrum etc wasn't a thing then else the hour would be spent in a stand up!!!

Re: Ask HN: Was the Y2K crisis real?

#104
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…

and it was pretty embarrassing when I forgot to update this same thing in 2010

Re: Ask HN: Was the Y2K crisis real?

#105
post #14

There were parts of our telecom infrastructure that weren't ready but got fixed before y2k. A certain mobile phone switching vendor (think cell towers, etc.) ran tests a year before to see what happened when it rolled over and the whole mobile network shut down (got in a wedged state where calls would fail, no new calls, signalling died). They fixed it and got customers upgraded in time.

I dont think I even had a mobile phone in 1999. Probably not a critical system back then.

Re: Ask HN: Was the Y2K crisis real?

#106

Earlier quoted context omitted.

It a shame that we as engineers can't just say "this maintenance is required to fix this known issue. It's not a huge deal but will cause trouble if it's not dealt with". Instead we have to be all doom and gloom and tell management that the company/world will end.

Colleague was just dealing with a clients of their who was still using TLS1.0. They're running classic ASP on Window Server 2008, and can't (effectively) migrate. Colleague had been raising the alarm for months (since they started on the project) that "this is going to mean all your systems will stop working in early 2020" but no one seemed to care or understand. They did, last week, put in ... haproxy as an SSL term…

We've been forced to deal with the TLS issue by our software product's customers. Some of our technically-minded folks have been raising the issue for a while but new features are sexy and sell, and fixing not-yet-broken code doesn't. Amazing/discouraging that only the threat of immediate loss of six figures of income gets any attention.

Re: Ask HN: Was the Y2K crisis real?

#107

Earlier quoted context omitted.

>> It's only hard to tell if you don't talk to the developers who were working in the late 90s. I think you mean "working ON it". Talking to developers as a broad group from that time wouldn't necessarily produce any useful information. The person you replied to was himself a developer working in the late 90s. During the late 90s, I talked to a lot of developers, but only a small percentage of them were on Y2K jobs.

There were a lot of Y2K related tasks in the course of many developers generally activity. Where I worked at the time, there were not developers solely dedicated to Y2K work. The Y2K issue pretty much caused an employment boom for software developers though.

It especially caused a boom for COBOL programmers, but not so much Java developers.

Re: Ask HN: Was the Y2K crisis real?

#108

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...

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…

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 I was working around Y2K and the apps on it - most delivered freely - make it far more capable than the raw processing power difference would indicate.

Re: Ask HN: Was the Y2K crisis real?

#109
post #80

We are lucky that the Y2k issue was so understandable by the public. I doubt we will have such luck addressing the Y2038 problem.

>We are lucky that the Y2k issue was so understandable by the public. As someone who was forced to spend Y2K in a "prepped" cabin on the side of a mountain with two years of supplies buried underneath, I think you might overestimate the quality of the public's response to Y2K. The public did not maturely understand that software needed to be updated and everything was OK. There was some real panic out there. It was a…

!!!

I think you might be using an unusual description of "the public"

Re: Ask HN: Was the Y2K crisis real?

#110

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...

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, approximately, gets() + strptime(), though I don't see any talk of error handling). Programmers probably just stuffed the result into a record before writing to DASD (disk), optimizing for programmer time and program complexity over storage.

Perhaps 2-digit years for ACCEPT were an optimization for data entry workers?

A modern z/OS COBOL guide [2] has 4-digit years throughout as far as I can see.

Whilst I'm here, I'm also going to say: "VSAM", "PDS", TSO", "LRECL" and "ABEND" (just because I haven't heard those words for a quarter century and now I'm feeling nostalgic).

[1] http://testa.roberta.free.fr/My%20Books/Mainframe/Fujitsu%20...

[2] https://www.ibm.com/support/knowledgecenter/SS6SG3_4.2.0/com...

Post reply on HN