Years since 1900 + seven bits = breakage in 2028
Last November, I put up a list of a bunch of "magic numbers" including some years in which time/date stuff is likely to break. There's 2036 for the NTP era rollover, 2038 for time_t requiring 32 bits in January *and* another GPS week rollover in November.
It turns out we have another one coming up far sooner, too: 2028!
Looking at the current year gives you a hint. It's 2021, but another way of looking at that is that we're 121 years past the year 1900. A fair number of things use(d) 1900 as an epoch, base year, or just an offset of sorts. Why? Well, they were probably invented in simpler times when the current year wasn't quite that far from 1900 at the time, and it would fit into fewer bits. Specifically, it'll fit into just seven bits... until 2028, that is.
Why would people do that? Assume they had limited bits to work with on the systems of the day. You need at least 11 bits to store a value in the neighborhood of our current years. Besides, at the time, 2028 probably looked like it was so far away that it'd never be a problem, because there's no way this stuff would still be use in by then, right?
So, if someone used 1900 as their base year, stored years relative to that, and then did it in just seven bits (or eight bits where one of them is a sign bit), it'll overflow in a little over six years. What happens then depends on which method was used, and whether it applies certain kinds of sanity checks.
Worst case, I guess it could interpret "year 128" as "year -127", and that would cause the system to roll from December 31, 2027 to January 1, 1773. Neat!
...
I originally spotted this thanks to a bug report type comment on an epitaph (!) on HN. That one is about ISO 9660 (CD/DVD stuff) software and how it handles years.
Something similar was found in the Linux kernel in 2015 (and appears to have been patched).
Out of curiosity, I went looking for more info and did find a reference to this same problem that might be useful if you're trying to keep your HP 3000 alive. You know, the things with the 300+ lb disk drives? (If you know, you know.)
Other than those pages, there's not a whole lot on the topic.
Wikipedia does have 2028 in their epic list of time formatting and storage bugs, naturally, but it only talks about systems from the '70s. It doesn't mention ISO 9660 at all - at the moment, that is. Perhaps someone in the know will update it and then this comment will be obsolete.
If you are responsible for a bit-constrained system that might be storing years this way, you owe it to everyone to go look and see what'll happen. Maybe try setting one forward to 2028-01-01 and see if it remains happy or if it decides to go party in the 18th century.
...
While I have your attention, for the younger set out there: as long as we're talking about bits and years, you aren't necessarily in the clear. You might've noticed that 11 bits will hold the whole year, as in 2021, with no offsetting needed. Perhaps you even designed a system that shaved things down to their minimum storage sizes based on this.
Eleven bits! Luxury! Ah, well, guess what happens in 2048? Yep!
...
Finally, one random thing for anyone who's not already aware: try log2(n) to get a feel for how big a number is in binary. Neat, right?