The Year 2036 Problem

Back in 1999 some people were freaking out because they thought that computers would stop working. That's because a lot of software stored the current year only as the last two digits, like 1984 was just 84. It was known as the year 2000 problem, or Y2K for short. They switched to Unix timestamps stored as signed 32-bit integers and everything was fine.

A Unix timestamp is the number of seconds since the beginning of the year 1970. It's often stored as a signed 32-bit integer, which can go up to 2^(32-1). That's only 68 years, and 1970+68 is 2036. Thus, we have a year 2036 problem.

The solution that comes to mind is to just use a bigger integer. Perhaps a 64-bit integer. But that only pushes the problem further down the line, right? That was my thinking, so I concocted a more far-reaching format for storing time:

yearlen (8 bits)
year (4 * yearlen bits)
month (4 bits)
day (9 bits)
millisecond (27 bits)

It stores the number of digits in the year number, then the year number itself, followed by the month, the day of the month, and the millisecond of the day. To store the current date in 2026 it would use 8+16+4+9+27 bits, which is 64 bits, the same size as the alternative. This date format can go up to the year 10,000 without needing to expand.

Then I did the math on how far an unsigned 64-bit integer can go. That's 2^64, which is 18,446,744,073,709,551,616 seconds, which is about 584,554,531,341 years. Wow. Seems like using an unsigned 64-bit integer is a much better idea than my rubbish.