5 ms·

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

by larrik 1y ago

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

cogman10 1y ago
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
- School-Cotton 1y ago
  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.
  - Y_Y 1y ago
    I think GP meant uint, but by my book int should have a sign bit, so that grampa isn't born in the future.
    - tremon 1y ago
      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.
  - cogman10 1y ago
    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
    - __d 1y ago
      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-clause https://www.mainframemaster.com/tutorials/cobol/picture-clau...
  - zerocrates 1y ago
    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.
- silvestrov 1y ago
  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.
  - exidy 1y ago
    https://en.wikipedia.org/wiki/Decimal_computer https://en.wikipedia.org/wiki/Decimal_computer
- Hemospectrum 1y ago
  > They could have represented dates as a simple int value In standard COBOL? No, they couldn't have.
  - cogman10 1y ago
    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.
  - colejohnson66 1y ago
    And COBOL can support four-digit numbers.
    - __d 1y ago
      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.
amelius 1y ago
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 ...
- eloisant 1y ago
  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.
  - amelius 1y ago
    Yeah, I don't remember the specifics.
  - Hikikomori 1y ago
    Is there an y2k unsafe Linux you can try in a VM?
    - pkaye 1y ago
      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.
      - deleted 1y ago
        [deleted]
  - throw0101d 1y ago
    > Little happened because work was done to prevent issues. * https://en.wikipedia.org/wiki/Preparedness_paradox https://en.wikipedia.org/wiki/Preparedness_paradox
  - bigstrat2003 1y ago
    > 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.
hans_castorp 1y ago
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.
GuB-42 1y ago
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.
- deleted 1y ago
  [deleted]
- account42 1y ago
  > 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.
GartzenDeHaes 1y ago
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.
- Per_Bothner 1y ago
  "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).
  - GartzenDeHaes 1y ago
    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.
- larrik 1y ago
  yeah, I shouldn't have said "bytes" either, especially as I had AS/400's in mind when I wrote it.
burnt-resistor 1y ago
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.

by larrik 1y ago

cogman10 1y ago

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

School-Cotton 1y ago
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.
- Y_Y 1y ago
  I think GP meant uint, but by my book int should have a sign bit, so that grampa isn't born in the future.
  - tremon 1y ago
    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.
- cogman10 1y ago
  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
  - __d 1y ago
    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-clause https://www.mainframemaster.com/tutorials/cobol/picture-clau...
- zerocrates 1y ago
  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.
silvestrov 1y ago
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.
- exidy 1y ago
  https://en.wikipedia.org/wiki/Decimal_computer https://en.wikipedia.org/wiki/Decimal_computer
Hemospectrum 1y ago
> They could have represented dates as a simple int value In standard COBOL? No, they couldn't have.
- cogman10 1y ago
  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.
- colejohnson66 1y ago
  And COBOL can support four-digit numbers.
  - __d 1y ago
    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.

amelius 1y ago

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

eloisant 1y ago
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.
- amelius 1y ago
  Yeah, I don't remember the specifics.
- Hikikomori 1y ago
  Is there an y2k unsafe Linux you can try in a VM?
  - pkaye 1y ago
    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.
    - deleted 1y ago
      [deleted]
- throw0101d 1y ago
  > Little happened because work was done to prevent issues. * https://en.wikipedia.org/wiki/Preparedness_paradox https://en.wikipedia.org/wiki/Preparedness_paradox
- bigstrat2003 1y ago
  > 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.

hans_castorp 1y ago

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.

GuB-42 1y ago

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.

deleted 1y ago
[deleted]
account42 1y ago
> 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.

GartzenDeHaes 1y ago

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.

Per_Bothner 1y ago
"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).
- GartzenDeHaes 1y ago
  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.
larrik 1y ago
yeah, I shouldn't have said "bytes" either, especially as I had AS/400's in mind when I wrote it.

burnt-resistor 1y ago

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.