The Year 2036 Problem

Back in 1999 some people were freaking out because they thought 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 stored as 84. It was known as the year 2000 problem, or Y2K for short. They switched to Unix timestamps 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 (i32), which can go up to 2^(32-1). If you do the math, that's only 68 years, so we'll be facing a similar problem 68 years after the year 1970. Thus, we have a year 2036 problem.

The solution that comes to mind is to just use a bigger integer. Perhaps an i64. You could use an unsigned integer (u64) to go even higher, but then you wouldn't be able to store time values prior to 1970. But using a bigger integer 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, then the year 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 integer 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 i64 can go. That's 2^(64-1), which is 9,223,372,036,854,775,808 seconds, which is about 292,277,265,671 years. Wow. Seems like using an i64 is a much better idea than my rubbish.