Hacker News Reader

Comment by victorbjorklund | Hacker News Reader

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

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.

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.

[1] - https://en.wikipedia.org/wiki/Unix_time

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

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

Reply on news.ycombinator.com