Let's restart counting Unix timestamp to from 2020
Old counting start date: Jan 01 1970 01:00:00 GMT+0100
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) Sounds a bit like a solution in search of a problem. 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. There's nothing ambiguous when the epoch is known and the previous one is long gone. So you're confused about restarting a timer every 50 years, ok. 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. 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. How does it require less implementation? It's just another arbitrary point in time and 2106 is too late. 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. 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. > 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/ And why not 2000 while you're at it, to keep it even? Starting a new epoch every 50 years is kind of round and leaves plenty of space in between. 1970 is epoch 1, so this one will be epoch 2 and the next one in 2070 will be epoch 3 etc. It will be easy in a few hundred years to know which epoch is the current one. 2020 not 2000 for backwards compatibility to keep the intervals even for the new epochs, because the first one is already baked everywhere so we can't switch it to 1950. Great idea - for shiny new systems, at new companies, that will never see any date older than Jan 1 2020. But for other use cases - not so great. For purposes that require looking far into the future or the past we already have ubiquitous 64 bit computers.
The goal is to be able to fit the measure of time in 32bits in a standard way even after year 38 to have an alternative to using only 64bit time. 32 bits can only fit so many seconds so the clock must be restarted from time to time. The idea is to have a new 32 bit epoch every 50 years. Why? We're slowly running out of time in 32 bits. It would be good to have another standard measure of time that fits in 32 bits and is agreed upon long before the old one expires It sounds like the problem being described is not that Unix epoch starts in 1970 but rather that it's 32 bit. Perhaps there is a way to make this 64 bits and maintain some backwards compatibility? I am not a proper developer so perhaps someone could postulate whether or not this would be feasible. [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. Sure, using 64bits is one way but many devices i.e. IOT don't need 64bit support. 64 bit will definitely be a standard, but a concurrent standard can be implemented to allow keeping the time in 32 bits. Starting a new epoch every 50 years could be one. So starting from 1 Jan 2020 we're in epoch 2 now How will we know which way to decode time data, then? You can't use timestamps, and adding an extra signing bit defeats the purpose. By assuming which epoch it is and it will be clearly a separate data type from the old unix epoch. Currently the assumption is the epoch which started in 1970. 50 years is long enough period of time to keep a standard and 18 years is long enough to switch to a new standard. With the updated standard it is simply epoch 2 now that is ignorant about any epochs before or after. Why not use a 64 bit value? Sure and it will be used widely. What I'm proposing is how to measure the time with only 32 bit used and the solution could be a new epoch every 50 years. _Why_ are you proposing a 32 bit solution that suffers from having to change the epoch every so often, given that we have a 64 solution that lacks this drawback? What’s the use case for it, where this would be a good trade off? For simple devices like IOT etc to be able to keep using the short 32bit date format. Also for databases that may store dates as integers to save the space. There are plenty of cases that may want to keep using a short 32bit date format. After 2038 anyone will be able to count 32bit time from any arbitrary point of time so before that happens I'm simply suggesting a standardized way of reliably restarting it for centuries to come