4 ms·

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 c

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.

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.