New counting start date: Jan 1 2020 00:00:00 UTC+0000
Example in Dev Tools how to get the new epoch time
const newBeginning = new Date('Jan 1 2020 00:00:00 UTC+0000')
const newEpoch = Date.now() - newBeginning.getTime()
console.log('New epoch timestamp', newEpoch)
There's no reason you can't use a 64-bit value in a 32-bit system. Much simpler to access the 64-bit value as two 32-bit words than propose a whole new confusing and ambiguous system.
In terms of current-time coding, the only time that second hi-order word would be used is when the lo-order word overflows, and on initialisation of the 64-bit variable. And if needs must, it could even be a compiled-in value, seeing it will only change once in every 68 years.
It's not true that it's much simpler to work with two 32bit words for a date than working with simply restarted clock. Basic arithmetics cannot be used reliably so every operation must go through a library like i.e. bigint used to require. This complicates the system and the goal of having a reliable 32bit date format in the future is for simplicity.
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.
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.
But for other use cases - not so great.
[Edit] Answering my own question it appears some systems have already addressed this by moving to 64 bit time [1] thus kicking the can down the road 292 billion years in both directions.
