[fargle]

here's an idea: instead of projecting a human concept of the roundness of a date onto the technical solution, let's use a value optimized for efficient implementation.

Obviously if you move toward 64 bits, as most systems have already done, you don't have a problem.

So if you want to stick to signed 32 bits, let's instead agree to restart counting 32 bit UNIX timestamps for the new epoch at exactly Sun Feb 7 06:28:16 AM 2106 UTC.

Sure, it's not a very round number in human terms, but has the advantage of requiring significantly less implementation.

Of course you still have the same problem of knowing which epoch you are in, but that's intrinsic to the problem when you only have 32 bits.

[touchpadder]

How does it require less implementation? It's just another arbitrary point in time and 2106 is too late.

[fargle]

You miss the point. On Jan 19 2038 at 03:14:07 UTC, the very next second of a signed (2's complement) 32 bit time will roll over from +2^31-1 to -2^31. Which happens to be -2^31 seconds before Sun Feb 7 06:28:16 AM 2106 UTC. So if you were just to interpret those negative dates as relative to 2106, you are good to go in 2038 without changing anything.

Any system of assigning epochs needs to have some method to determine which epoch you are referring to, so that's no different no matter if the scheme starts in 2020, 1970 2040, etc. So just use the natural modulus of 2^32 if you are using signed 2^32 to represent dates. When it rolls over, you're in a new epoch.

I'm kind of trying to point out that if you have a calendar that repeats after every 2^32 seconds, and you have more than 2^32 seconds to count, your problem is that you have too small of a counter, not wherever the arbitrary start point is - changing that is silly and just adds complication.

[touchpadder]

Using negative values would only complicate things and the goal is to have a simple solution for not losing convenience of having a unix timestamp that fits in 32bits and is very straightforward.

In 99.9% cases there will be no need to keep track of the epoch just like the current computers don't look before 1970. In rare cases if its required the epoch can obviously be stored in another byte.

[fargle]

> Using negative values would only complicate things

how so? as it happens computers handle this automatically when using a signed 32 bit integer. It's easy to implement because there is literally no extra work.

> In 99.9% cases there will be no need to keep track of the epoch just like the current computers don't look before 1970

so then why would you not suggest using unsigned 32 bits and going straight to 2106 that way?

I think you need to take some time and get comfortable with both 2s complement and modular arithmetic to understand the right trades for a solution to 2038 and why creating yet a new date standard of 2020 isn't a better idea than what's already been done and several other things that could have been. There are a lot of other gotchas and design decisions. That's why what I suggest is somewhat tongue in cheek and not a serious proposal. But it's objectively better in all criteria than starting again with 2020 (or 2000, or ...).

I leave you with: https://xkcd.com/927/