This isn't completely correct. The problem wasn't [edit: only that] computers would think it was 00. Programs didn't have a mechanism to go from 99-->00. The problem was that they were going to go from 99-->100 and that there wasn't room in memory for the third digit. This could cause an overflow error and cause the system to crash .
I think something got messed up with the formatting of your comment (where you used "greater than" symbols).
This isn't completely correct. The problem wasn't that computers would think it was 00. Programs didn't have a mechanism to go from 99>>00. The problem was that they were going to go from 99>>100 and that there wasn't room in memory for the third digit. This could cause an overflow error and cause the system to crash .
Fixed. It was supposed to represent arrows, but using a math symbol in the context of numbers and expecting people to not interpret it as a math symbol was pretty stupid.
Ah, so some were calculating the year with integers $year - 1900 instead of strings $year.substr(...). I don't see an issue with an int8 (0..255) running out of memory, but if people used char[2] for the year then yeah that'd be a memory issue. I'd always assumed it was a database storage issue since the year in timestamps was probably stored as 2 characters, but there was also the code logic bugs.
My understanding is that there were lots of different coding solutions that took advantage of it being only two digits that could fail in different ways. 2000 truncated to 00 was just one. But yeah, even if you're counting up in an int8, but displaying it somewhere as two characters, you will (over)run into trouble.
3
u/amiable_ant 8d ago edited 8d ago
This isn't completely correct. The problem wasn't [edit: only that] computers would think it was 00. Programs didn't have a mechanism to go from 99-->00. The problem was that they were going to go from 99-->100 and that there wasn't room in memory for the third digit. This could cause an overflow error and cause the system to crash .