Hacker News Reader

Comment by larrik | Hacker News Reader

> Readers of a certain vintage will remember well the "Y2K problem," caused by retrospectively shortsighted attempts to save a couple of bytes by using two-digit years – meaning that "2000" is represented as "00" and assumed to be "1900."

This seems overly harsh/demeaning.

1. those 2 bytes were VERY expensive on some systems or usages, even into the mid-to-late 90's

2. software was moving so fast in the 70s/80's/90's that you just didn't expect it to still be in use in 5 years, much less all the way to the mythical "year 2000"

View on HN

And we still use 2 digit years!

For example, credit cards often use the mm/yy format for expiration dates because it is more convenient to write and considering the usual lifetime of a credit card, it is sufficient. But it means there is a two digit date somewhere in the system, and if the conversion just adds 2000, we are going to have a problem in 2100 if nothing changes, no matter how many bytes we use to represent and store the date. A lot of the Y2K problem was simple UI problems, like a text field with only 2 characters and a hardcoded +1900.

One of the very few Y2K bugs I personally experienced was an internet forum going from the year 1999 to the year 19100. Somehow, they had the correct year (2000), subtracted 1900 (=100) and put a "19" in front as a string. Nothing serious, it was just a one-off display error, but that's the kind of thing that happened in Y2K, it wasn't just outdated COBOL software and byte savings.

> One of the very few Y2K bugs I personally experienced was an internet forum going from the year 1999 to the year 19100. Somehow, they had the correct year (2000), subtracted 1900 (=100) and put a "19" in front as a string. Nothing serious, it was just a one-off display error, but that's the kind of thing that happened in Y2K, it wasn't just outdated COBOL software and byte savings.

POSIX struct tm (which e.g. PHP wraps directly) contains the year as a counter since 1900.

This is a case where "premature optimization" would have been a good thing.

They could have represented dates as a simple int value 0ed at 1900. The math to convert a day number to a day/month/year is pretty trivial even for 70s computers and the end result would have been saving more than just a couple of bytes. 3 bytes could represent days from 1900->~44,000 (unsigned).

Even 2 bytes would have bought ~1900->2070

There were plenty of people born in 1899 who were still alive in 1970, so you couldn't e.g. use your system to store people's birth dates.

Of course you couldn't with 2 digit years either, or at least not without making more changes to move the dividing line between 1900s/1800s down the line.

Cut the upper range in half, use 3 bytes and 2's compliment.

That gives you something like 20,000BCE -> 22,000CE.

Doesn't really change the math to spit out a year and it uses fewer bytes than what they did with dates.

I will say the math gets more tricky due to calendar differences. But, if we are honest, nobody is really caring a lot about March 4, 43-BCE

COBOL PIC clauses aren’t able to deal with bit twiddling. And that’s what a lot of this stuff was using.

See eg. https://www.mainframemaster.com/tutorials/cobol/picture-clau...

I think GP meant uint, but by my book int should have a sign bit, so that grampa isn't born in the future.

The only reason why a system can only represent the range from 1900-1999 is when the system uses characters (ascii decimal digits) or BCD encoded digits. It would have been very unlikely for any integer-based encoding system to have had a cutoff date at 1999 (e.g. int8 would need an epoch at 1872 to rollover after 1999), so I don't think signed vs unsigned makes a difference here.

A lot of the old systems don't use bytes/ints the same way as the C programming language.

Many systems stored numbers only in BCD or text formats.

https://en.wikipedia.org/wiki/Decimal_computer

> They could have represented dates as a simple int value

In standard COBOL? No, they couldn't have.

The average programmer couldn't have, the COBOL language authors could.

COBOL has datatypes built into it, even in COBOL 60. Date, especially for what COBOL was being used for, would have made a lot of sense to add as one of the supported datatypes.

And COBOL can support four-digit numbers.

The problem was mostly that storage was expensive.

It’s difficult to understand in an era of cheap terabyte SSDs, but in the 1960s and 1970s, DASD (what IBM mainframes called hard drives) was relatively tiny and very expensive.

And so programmers did the best they could (in COBOL) to minimize the amount of data stored. Especially for things that there were lots of, like say, bank transactions. Two bytes here and two bytes there and soon enough you’re saving millions of dollars in hardware costs.

Twenty years later, and that general ledger system that underlies your entire bank’s operations just chugging along solidly 24/7/365 needs a complete audit and rewrite because those saved bytes are going to break everything in ten years.

But it was probably still cheaper than paying for the extra DASD in the first place.

People aren't getting that it was two characters that need to be added, not two bytes to make a short into an int. COBOL uses a fixed width character format for all data (yes even for COMP). If you want a four digit number, then you have to use 4 character positions. Ten digits? Then ten characters.

These field sizes have to hard coded into all parts of the COBOL program including data access, UI screens, batch jobs, intermediate files, and data transfer files.

"COBOL uses a fixed width character format for all data (yes even for COMP). If you want a four digit number, then you have to use 4 character positions."

That is incorrect. USAGE COMP will use binary, with the number number of bytes depending on the number of digits in the PIC. COMP-1 specifically takes 4 bytes. COMP-3 uses packed decimal (4 bits per digits).

That's what the specs say, but I found out it actually didn't work that way when I was working on a transpiler, at least for that installation.

yeah, I shouldn't have said "bytes" either, especially as I had AS/400's in mind when I wrote it.

I was working on a COBOl program in the late 80's that stored the year as a single digit value. Sounded totally stupid when I was explained the structure. But records were removed after 4 years automatically, so it wasn't a problem, it was always obvious which year was stored.

I know people who bought large amounts of put options just before Y2K, thinking that the stocks of large banks would crash. But little happened ...

Little happened because work was done to prevent issues.

Also it was a bit dumb to imagine the computers would crash at 00:00 on Jan 1st 2000, bugs started to happen earlier as it's common to work with dates in the future.

As an example, I started working on Y2K issues in 1991, and it was a project that had been running for several years already. It was an enormous amount of work, at least 25% of the bank’s development budget for over a decade.

30 year mortgages were the first thing that was fixed, well before my time. But we still had heaps of deadlines through the 90’s as future dates passed 2000.

The inter-bank stuff was the worst: lots of coordination needed to get everyone ready and tested before the critical dates.

It’s difficult to convey how much work it all was, especially given the primitive tools we had at the time.

> Also it was a bit dumb to imagine the computers would crash at 00:00 on Jan 1st 2000, bugs started to happen earlier as it's common to work with dates in the future.

That is why people have the "nothing happened" reaction. There were doomers predicting planes would literally fall out of the sky when the clock rolled over, and other similar Armageddon scenarios. So of course when people were making predictions that strong, everyone notices when things don't even come close to that.

> Little happened because work was done to prevent issues.

* https://en.wikipedia.org/wiki/Preparedness_paradox

Is there an y2k unsafe Linux you can try in a VM?

Linux (and probably most Unix systems) use a 32 bit time counter so didn't have the Y2K issue. But there might have been some applications that had it. And its possible some early bios clocks used 2 digit year that had to be worked around.

Yeah, I don't remember the specifics.

For RTC storage in CMOS using a BCD byte, one could assume that the epoch was relative to, say the decade of manufacturing (suppose 1990) such that dates roll over from 99 to 00 could instead create a Y2090 problem:

    Y = (yy < 90) ? (2000 + yy) : (1900 + yy);

This would have to be handled differently than something that was required to be IBM PC or IBM AT compatible with every compatible quirk. It's simply a way to save 8-bits of battery-backed SRAM or similar.

Reply on news.ycombinator.com