Time is an illusion, Unix time doubly so

From the GNU coretutils doc [1]:<p>Our units of temporal measurement, from seconds on up to months, are so complicated, asymmetrical and disjunctive so as to make coherent mental reckoning in time all but impossible. Indeed, had some tyrannical god contrived to enslave our minds to time, to make it all but impossible for us to escape subjection to sodden routines and unpleasant surprises, he could hardly have done better than handing down our present system. It is like a set of trapezoidal building blocks, with no vertical or horizontal surfaces, like a language in which the simplest thought demands ornate constructions, useless particles and lengthy circumlocutions. Unlike the more successful patterns of language and science, which enable us to face experience boldly or at least level-headedly, our system of temporal calculation silently and persistently encourages our terror of time.<p>… It is as though architects had to measure length in feet, width in meters and height in ells; as though basic instruction manuals demanded a knowledge of five different languages. It is no wonder then that we often look into our own immediate past or future, last Tuesday or a week from Sunday, with feelings of helpless confusion. …<p>—Robert Grudin, Time and the Art of Living.<p>[1] <a href="https:&#x2F;&#x2F;www.gnu.org&#x2F;software&#x2F;coreutils&#x2F;manual&#x2F;html_node&#x2F;Date-input-formats.html" rel="nofollow">https:&#x2F;&#x2F;www.gnu.org&#x2F;software&#x2F;coreutils&#x2F;manual&#x2F;html_node&#x2F;Date...</a>

I&#x27;m still of the opinion that handling leap seconds by ignoring them is a dumb idea.<p>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&#x2F;implementation-defined&#x2F;an exercise for the reader&#x2F;whichever variation of &quot;not my problem&quot; you prefer.

ICYMI: The title is a reference to The Hitchhiker&#x27;s Guide to the Galaxy: <a href="https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;The_Hitchhiker%27s_Guide_to_the_Galaxy" rel="nofollow">https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;The_Hitchhiker%27s_Guide_to_...</a> (&quot;time is an illusion, lunch time doubly so&quot;)

Worked for a company recently that does test equipment for timing and sync.<p>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.<p>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.<p>It was a very interesting domain to work in even though I only was do the app part of the thing. Didn&#x27;t pay enough though and I was promised a promotion that never came.

<i>&quot;On Unix systems we measure time as the number of seconds since &quot;the epoch&quot;: 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.&quot;</i><p>Well, seconds have not been defined as &quot;a convenient fraction of the time it takes a particular large rock to complete a full rotation around its own axis&quot; for quite some time, and the origin is set to an abstract event in the past, which is not (as far as I know) subject to retroactive revision as a consequence of the vagarities of planetary or celestial motion (if it is, I would be fascinated to know more.)

Very interesting detail about linux and setting the time back to a value such that the boot time is before the epoch, with monotonic clocks.<p>Shamelessly I&#x27;ll here remind people to never use gettimeofday() to measure time. E.g. setting the time backwards used to cause any currently running &quot;ping&quot; command to hang. (they fixed it about 10 years after I sent them a patch)<p>More fun examples of bugs like that at <a href="https:&#x2F;&#x2F;blog.habets.se&#x2F;2010&#x2F;09&#x2F;gettimeofday-should-never-be-used-to-measure-time.html" rel="nofollow">https:&#x2F;&#x2F;blog.habets.se&#x2F;2010&#x2F;09&#x2F;gettimeofday-should-never-be-...</a>

A long time ago -- late 1980s -- I worked in system software, VMS-based, at DEC.<p>Sometimes we used, for dev and testing, dedicated machines running with clocks set 20-25 years in the future. (They was a measurable investment of capital, power, and cooling back then.) This was smart: the remnants of DEC were able to sidestep the whole Y2K cluster**k.<p>Are our key tech vendors doing the same now? It&#x27;s about a quarter century until the 2038 fin-de-siecle. I sure would like some assurance that the OSs, DBMSs, file systems, and other stuff we all adopt today will have some chance of surviving past 2038-01-19.<p>I know redefining time_t with 64 bits &quot;solves&quot; the problem. But only if it gets done everywhere. Anybody who&#x27;s been writing programs for more than about 604 800 seconds has either thought through this problem or hasn&#x27;t.

Great blog post. Sometimes it&#x27;s useful while testing to set random future and past times on Unix systems to see how programs handle that.<p><a href="https:&#x2F;&#x2F;blog.darkinfo.org&#x2F;timestomp-for-linux&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.darkinfo.org&#x2F;timestomp-for-linux&#x2F;</a>

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.<p><a href="https:&#x2F;&#x2F;news.mit.edu&#x2F;2022&#x2F;quantum-time-reversal-physics-0714" rel="nofollow">https:&#x2F;&#x2F;news.mit.edu&#x2F;2022&#x2F;quantum-time-reversal-physics-0714</a>

Loved the article! There are so many great details such as the standardization of UTC happening after UNIX time invented, UNIX itself being born before the epoch, and all the great insight into the morass of 64 bit time across modern OSes.<p>Putting on my pedantic hat though, I see that East and West were switched in the discussion of Japan&#x27;s unique 50&#x2F;60Hz AC frequency split, and I can&#x27;t get my mind off it. Hope you can make the edit.

There have been patches the last ten years to lessen the impact of 2038, considering how close that is this is a bit worrisome. Nice to see a comparison of different systems like this, but you probably need to track this over time in some way. E.g Pretty sure Gnu date has seen patches about this in the last years.

The article missed an opportunity to describe how spectacularly can things break when the 32-bit time_t overflows in Y2038.<p>If you still have such a machine (preferably without any valuable data), try setting the date right before the overflow with this command<p>date -s @$[2**31 - 10]<p>and see if you can recover the system without reboot.<p>I have seen different daemons stopped responding and just consuming CPU, NTP clients flooding public servers, and other interesting things. I suspect many of these systems will still be running in Y2038 and that day the Internet might break.

Bottom line is: time is quite complicated, and things get messy when you try to overload different usages or engineering constraints. Including but not limited to:<p>- small, limited, and&#x2F;or fixed data size<p>- compatibility across systems<p>- range of expressable times<p>- monotonicity (either locally or distributed)<p>- express absolute datetimes accurately<p>- express relative offsets accurately<p>- accurate over very short or very long timescales (or both)<p>- synchrony to solar noon<p>- synchrony to sidereal time<p>- timezones<p>- relativisitc effects<p>Pick any, uhhh, well pick as many as you can and try to shoehorn them together and you get your typical time implementation.

Real-time: TAI64 TAI or go home.<p>Earth time: UT (UT1).<p>UTC is a vague approximation of UT1 using TAI and a leap seconds data source similar to tzdata.<p>On most modern CPUs, there is an accurate monotonic counter. The problem though is it doesn&#x27;t know anything about when it was started or when it went to sleep in any time system.<p>Oh and bugs. Some systems interpret edge cases in one way, and others in others. Academic purity, interoperability: pick 1.<p>And then calendars are discontinuous through the years: October 15, 1582 and twice in 1752. They also vary by country which calendar system was in use when. The Julian and Gregorian calendars were in dual use until 1923.<p>Daylight savings time rules change. Timezones change. And then you get tzdata.<p><a href="https:&#x2F;&#x2F;www.stjarnhimlen.se&#x2F;comp&#x2F;time.html" rel="nofollow">https:&#x2F;&#x2F;www.stjarnhimlen.se&#x2F;comp&#x2F;time.html</a><p><a href="https:&#x2F;&#x2F;cr.yp.to&#x2F;proto&#x2F;utctai.html" rel="nofollow">https:&#x2F;&#x2F;cr.yp.to&#x2F;proto&#x2F;utctai.html</a>

Maybe I am misunderstanding the post, but for me the beauty of Unix time is precisely that all the weirdness with dates is abstracted away to the &quot;conversion code&quot; so that you only deal with &quot;seconds&quot;. Timezones, leap seconds... all of that only matters when you&#x27;re showing the user a date. For recording and calculations, it doesn&#x27;t.

Excellent write up, with very nice humorous style and clearly explaining the situation with the year 2038 problem.

From Beat The Devil (1953):<p>Time. Time. What is time? Swiss manufacture it. French hoard it. Italians squander it. Americans say it is money. Hindus say it does not exist. Do you know what I say? I say time is a crook.

There is one kind of time that is real and important. That is naptime.

Haven&#x27;t astronomers already found a way to solve this problem? by using the standard Epoch.<p>&quot;there has also been an astronomical tradition of retaining observations in just the form in which they were made, so that others can later correct the reductions to standard if that proves desirable, as has sometimes occurred.&quot; [<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Epoch_(astronomy)" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Epoch_(astronomy)</a>]

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.

What a mess. (Plus, time is relative, i.e. it depends on the frame of reference.)

Site is getting hammered: <a href="https:&#x2F;&#x2F;archive.ph&#x2F;eUeFa" rel="nofollow">https:&#x2F;&#x2F;archive.ph&#x2F;eUeFa</a>

<p><pre><code> UNIX time, like all times, is a very good one, if we but know what to do with it. -Ralph Waldo Emerson</code></pre>

very interesting stuff. wondering is there any in-depth walkthrough of the time keeping mechanisms in Linux?

This is why I eat Unix time for lunch.

Time is a flat circle.