>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<10; 
    date="20$year"
  else 
    date="19$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....

A much more insidious problem with the Y2K bug was the leap year calculation. As you point out, the 20-digit-year thing was relatively easy to fix.

https://en.wikipedia.org/wiki/Year_2000_problem#Leap_years

I still love the fact that if you only implemented the first rule or had the knowledge to implement all 3 rules, it would totally work, but if you implemented 2 of the 3 rules you were wrong.

It taught me a great lesson about results not proving correctness as how you got there could bite you later.

I don't get why people don't know all three rules. In elementary school when the calendar is taught, the complete rules of the leap year were simply taught by the teacher. We even joked about people born on the 29th of February. Why wasn't this taught everywhere?

Heh, this sentence seems particularly relevant to this whole discussion...

> This method works fine for the year 2000 (because it is a leap year), and will not become a problem until 2100, when older legacy programs will likely have long since been replaced.

Wouldn't it be this?

    date="200$year"

Or does foxpro somehow know to zero pad a 1 digit number?

It's been a very long time since I've worked with dBASE/FoxPro, but from what I remember it stores data in a fixed-width format. So for a column to store an integer, it will zero pad the front of it to fit the width of the column.

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.

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

Man, I've just remember that I had to fix this kind of bug in 2010 and I am sure I just bumped the number to 20. I guess somebody had to be fixing it lately, I just hope they didn't just replace 2 with 3.

I'll bet they did. Or, if they were proactive/out performer, they changed it to 4 or 5 and just solved the problem for the next 20-30 years.

> 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 < n ? 2000 : 1900' was such an easy workaround, for n=20,30,40,...

https://www.pymnts.com/news/payment-methods/2020/new-years-b...

There was a related story here on HN recently. A system was assuming a 101-year-old was actually only 1 year old, presumably because of 2 digit arithmetic.

https://news.ycombinator.com/item?id=22356373

They were a modulo 100 1-year-old. Modulo 100 ages: feature, not a bug.

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.

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

You're making an assumption in that statement that there's a byte and it's eight bits in length. This was not always true. Punch cards didn't really work that way, and fair number of CPU's didn't either.

Early machines used various decimal systems and 6-bit characters were widespread also. This explains a bit of why the C language and descendants often have native support for Octal literals and Unix permissions are built around three bit groupings.

On a personal note, even in the very early 90's, I also remember using a CDC machine (a descendant of Seymour Cray's 6600) that supported 60-bit words with 6-bit characters. Pressure to move to 64 bit words with 8-bit bytes resulted in dual mode design that could be booted either way.

CDC...if it was like the CDC system I worked on back in the early 80s, the 6-bit chars (64 distinct chars, including control chars) did not include lower case Latin. Our system was munged so that lower case alphabetic chars could be represented by prefixing a backslash. I wrote my dissertation on that system, and fortunately the editor I used displayed a backslashed char as lower case.

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

What about "JCL" ? Those ABENDs don't just show up on their own.

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.

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.

You need also to have the code to do the conversion. If you store, in a byte, the years since 1900 (or 1970) then every time you load and/or process a date to be displayed you need to add 1900 (or 1970) and then convert from int to str which takes time (machines were slow) and code.

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.

BCD (Binary-coded decimal) comes to mind; which can store values 0-99 in one byte and with native support in older CPUs.

One of my tasks for Y2K prep was to modify an in-house-developed record-based "database" to accommodate a the century change. Originally developed in the '60s the year had originally been a single digit because everyone thought commercial DBMS' would be viable in few years so there would be a replacement before the decade rolled over. :-| They'd grafted decade handling into the thing before I got there so it could survive the '70s because they had a lot of expensive data in various file sets that contained the data. Converting to a commercial database was expensive and represented a huge business risk, so...

If you have eight bit bytes, you would of course store these as three two digit BCD numbers requiring one byte each, and need no conversion logic. (The code for printing BCD numbers is already there, because you need it to print amounts of money anyway).

A whole byte for a year? What a waste in 1995 when you've got just 640KB for DOS, your code and your data.

I looked up my old code. Shave off a bit of the year and:

  struct Date { 
       unsigned day : 5; 
       unsigned month : 4; 
       unsigned year : 7; 
    };

a full date in 16 bits. (well, in borland C++ 5 at least)

and as it was an accounting application, working with the bitfields was so much nicer than ordinal days you would use nowadays.

month and years was all you really cared about anyway when summarising data. in finance all months have 30 days anyway.

the problem came from the 60's when memory was really expensive on mainframes and you had things like drum storage

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

Then you would need another column on the card, and there are even fewer columns on a card than there are bytes in RAM.

The punched card, for a long time, _was_ the storage.

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.

This is the accurate point. We had epoch date tracking since the 1960s or so and the coding of a two digit year was out of laziness and convenience in most cases. And not bashing anyone, but most of the systems I saw using the lazy method were more business systems where there wasn't thoughtful engineering a lot of the time, but more just get it done. Those two don't have to be mutually exclusive IMO, but in the 70s/80's it seems a lot of the time it was, simply because IMO we had predominately really two classes of developers, scientific and business where business devs took less of an engineering mindset and more get it done in a specific timeframe so they "hacked" it out. Plus it was new, so stuff happens.

Sadly this stuff still goes on today, just in slightly different ways. Data type and data structure choices are critical, and it isn't as important to me that someone know how to write an algorithm for a RB-tree (or pick your DS), but it is critical an engineer knows which data structure/type to choose for specific use cases. This is one of my biggest complaints with the way a lot of engineering interviews are structured today, they want you to regurgitate known algorithms which is a waste of time and personal memory, find out if the person knows when they'd use a specific data structure and why the rest is easily researched. I mention this because to me the fundamental flaw of the y2k problem was one of data structure and data type choice.

Seconds since the epoch doesn’t work for times in the future. Consider a contract that will terminate at 2025-02-28 12:00 in New York: will that be -05:00 or -04:00? It could change.

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.

>> And the 20-year-old systems are slowly dissapearing There's still COBOL code out there running core business systems that's older than I am, and I'm closer to 60 than I am to 50.

One system I worked on showed the date as year 3900, because the function for getting current year would return 2 digit for year < 2000, and full 4 digit for >= 2000. So the code did 1900 + GetYear(). Replaced it with just calling GetFullYear() or something like that.

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 terminator in front of the main server, and will test a switch over this week. This was 8 months of foot-dragging for about 3 hours of setup/config, and a couple more hours of testing. When all your clients are hitting a web server, and their browsers will all stop rejecting your certs, things will get ugly fast - as in "your business will effectively stop functioning". It just sounded like "doom and gloom" but... how do you message this effectively? It requires the receiving parties to actually understand the impact of what you're saying, regardless of terms you use.

Money, Money is the way you talk that makes business listen.

You say "If we don't solve this by X date, we are looking at losing the ability to take in revenue and possible law suits for failure to perform. It will take Y amount of time to accomplish this"

If you don't couch things in terms of time, money, resources, client impact. They will not care. You can say "Hey, it is super bad that we are running Tomcat 7.0.0 there are a lot of security vulnerabilities" and what they will hear is "blah, blah, blah, we can delay this".

I hope your colleague had a paper trail of the alarms he raised when it came time to point fingers.

For executives with limited IT experience I honestly don't know if there is a good solution, other than having them deal with the disaster and having a clear paper trail that points the finger in their direction. They won't make the same mistake twice.

He did/does.

> How do you message this effectively?

Assuming the entire org is using a captive proxy with an installed CA, identify/isolate every upper-level management person's system(s) in some way, and reroute their access to all internal applications through a deliberately horribly misconfigured HTTPS reverse proxy running TLS 1.0. Their modern browser will explode.

"AAAA, sorry, that thing we've been telling you about for months hit us earlier than we thought it would but thankfully it's only hit all the internal stuff"

"Wait so this is what all of our customers will see?"

"Yes, all of them. Nobody will be to reach us, none of our APIs will work, and we will also break our SLAs on every single contract."

---

You probably want to use GPO to disable bypassing the security warning prompt, and/or set up HSTS for your domains beforehand.

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.

Yeah... "let's do Fitbit integration!" seems to win out over "let's make sure we can upgrade core systems to make sure they don't break in March".

Similar story, had an older version of MySQL on a 2008r2 server until a few weeks ago.

Advocating for 2 years to migrate off that box.

That client wouldn’t happen to be a small private college in WNY, would it?

No. :)

I'd argue if it wasn't for the media "doom and gloom" a lot of companies (maybe even the vast majority), would not have had their C level folks divert money towards fixing the issue.

The simple reason is that any one company may have been liable for a very small portion, which if it failed, would not have caused much trouble. But that failure combined with many other failures down the entire chain of connected and unconnected software would have added up to something much greater than the sum of parts.

We saw similar stuff happen with Flash, Silverlight (which wasn't as reported a concern since silverlight usage was so low, but I saw it within my company).

The media pressure was a significant reason why every company needed to have a plan to deal with it.

> but the media hyped it into a frenzy because

Because they make more money if people are scared and clicking refresh every few minutes.