41–50 of 104 posts
ICYMI: The title is a reference to The Hitchhiker's Guide to the Galaxy: https://en.m.wikipedia.org/wiki/The_Hitchhiker%27s_Guide_to_... ("time is an illusion, lunch time doubly so")
> Vell, I'm just zis guy, you know?
(A quotation from Gag Halfrunt, Zaphod Beeblebrox's "personal brain care specialist".)
I was surprised to learn that Linux has a “2262 problem” because of 64-bit time being used to store nanoseconds rather than seconds. That seems like a huge problem without an easy solution either. Yes there are almost 250 years to fix it but it seems like surprisingly bad planning. In any case it’s an interesting thought exercise to imagine what the fix should be.
I was surprised to see that very few systems other than computer (servers and suchlike) use unix timestamps. So GNSS systems have their own representation of time and the protocols that most network equipment uses is called PTP. Now-a-days most are trying to use the white rabbit protocol.
I was at a conference on this and there are a lot of crazy applications of these timing and sync technologies. The main is in 5G networks but the high frequency trading companies do all of there trading in FPGAs now to reduce time to make a decision so accurate timing is essential. Even the power companies are need high accuracy time to detect surges in powerlines. I spoke to someone from Switzerland who said they had serious security concerns as the timing fibres are poorly secured and open to easy disruption.
It was a very interesting domain to work in even though I only was do the app part of the thing. Didn't pay enough though and I was promised a promotion that never came.
I'm still of the opinion that handling leap seconds by ignoring them is a dumb idea. Unix time should be a steady heartbeat counting up the number of seconds since midnight, January 1 1970. Nice, clean, simple. How you might convert this number into a human-readable date and time is out of scope/implementation-defined/an exercise for the reader/whichever variation of "not my problem" you prefer.
The article makes a passing reference to atomic clocks, which are fascinating. The folks over at MIT are working on improved clocks that can get below 100ms error over the the current lifespan of the universe. https://news.mit.edu/2022/quantum-time-reversal-physics-0714
- small, limited, and/or fixed data size
- compatibility across systems
- range of expressable times
- monotonicity (either locally or distributed)
- express absolute datetimes accurately
- express relative offsets accurately
- accurate over very short or very long timescales (or both)
- synchrony to solar noon
- synchrony to sidereal time
- timezones
- relativisitc effects
Pick any, uhhh, well pick as many as you can and try to shoehorn them together and you get your typical time implementation.
UNIX time, like all times, is a very good one, if we but know what to do with it. -Ralph Waldo Emerson"On Unix systems we measure time as the number of seconds since "the epoch": 00:00:00 UTC on January 1st, 1970.... this definition is not based on something sensical such as, say, the objective frequency of vibration of a Cesium-133 atom, but on a convenient fraction of the time it takes a particular large rock to complete a full rotation around its own axis." Well, seconds have not been defined as "a convenient frac…
> seconds have not been defined as "a convenient fraction of the time it takes a particular large rock to complete a full rotation around its own axis" for quite some time That is true. > origin is set to an abstract event in the past That is also true. > which is not (as far as I know) subject to retroactive revision as a consequence of the vagarities of planetary or celestial motion I'm afraid you are wrong on that…
No, it isn't. The very article you linked explains that Unix time is monotonically increasing and ignores leap seconds.