3 ms·
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.
by 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 agoI 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 agoThe 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 agoCut 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 agoCOBOL 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 agoOf 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.