Old counting start date: Jan 01 1970 01:00:00 GMT+0100<p>New counting start date: Jan 1 2020 00:00:00 UTC+0000<p>Example in Dev Tools how to get the new epoch time<p>const newBeginning = new Date('Jan 1 2020 00:00:00 UTC+0000')<p>const newEpoch = Date.now() - newBeginning.getTime()<p>console.log('New epoch timestamp', newEpoch)
Sounds a bit like a solution in search of a problem.<p>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.<p>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.
here's an idea: instead of projecting a human concept of the <i>roundness</i> of a date onto the technical solution, let's use a value optimized for efficient implementation.<p>Obviously if you move toward 64 bits, as most systems have already done, you don't have a problem.<p>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.<p>Sure, it's not a very round number in human terms, but has the advantage of requiring significantly less implementation.<p>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.