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.
… 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. …
> "When it comes to the flow of time on those satellites, there are two important aspects related to Einstein’s theories of relativity. Special relativity states that a fast moving object experiences time dilation – its clocks slow down relative to a stationary observer. The lower the altitude the faster the satellite’s velocity and the bigger the time slowdown due to this effect. On the flip side, general relativity states that clocks run faster in lower gravitational field, so the higher the altitude, the bigger the speedup is."
> "Those effects are not even and depending on altitude one or the other dominates. In the demonstration below you can witness how the altitude of a satellite affects the dilation of time relative to Earth..."
There's also a nice if complex explanation of why your GPS receiever needs four satellite emitters to calculate the time bias of its clock.
> Special relativity states that a fast moving object experiences time dilation – its clocks slow down relative to a stationary observer.
For more fun: A less known fact is that SR also states that from the POV of the satellite, the satellite is a stationary observer and the guy on earth is fast moving, therefore that observer's clock slows down relative to the satellite.
Yes, that's right: Each of them sees the other one's clock as slower.
IIRC It takes the fact that the satellite moves in an orbit, not in a straight line, to resolve which one is actually "slower" because up until then, the word "slower" isn't really meaningful at all.
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.
> Unix time should be a steady heartbeat counting up the number of seconds since ...
This is nice and clean, so long as you have exactly one computer. The second there are more than one, and they are talking to each other, their clocks can go out of sync with each other. And they will, because they are physical systems that are imperfect and in general much less precise than you'd expect them to be.
This means that there has to be a way to correct for errors. The best method, that almost everyone who manages a lot of computers converges onto, is to "smear out" any errors, by never discretely changing the time on any machine, but just shortening or lengthening seconds slightly to bring any outliers back to the correct values. And once you have this system, dealing with a leap second using it is the easiest, simplest and least errorprone method.
I do think that there are purposes where local "machine time", which is just a monotonic clock counting upwards from bootup, would make sense. Especially when subsecond accuracy is important. But it should always be clear that there is no way to reliably convert between that and wallclock or calendar time. There are *no* intervals of calendar/wallclock time that reliably convert to any interval of machine time. It is not guaranteed that any wallclock minute contains exactly 60 machine seconds.
I think people forget how often computers in the 80’s and 90’s were turned off, keeping track of time with a backup battery, and just how many machines had a dead backup battery and users that didn’t know any better.
I fielded tech support questions from an app that had grown to send email. Every week we got a couple of emails from some time on January 1, 1970, each from a new person, and a whole slew of people whose batteries were on the edge of failing and so their machine was days or months off from reality.
The HTTP 1.0 spec already had a solution for two machines with different ideas of the current date. It’s one of my favorite parts of the spec and I’ve used it a few times in order to avoid having to implement my own time negotiation protocols (or in fact to stop others from doing it).
I don’t think that battery chemistry has changed all that dramatically since that time. It was still a 2032 cell, for machines that have a discrete battery. Instead it’s the clock chip and network time protocols that have gotten more efficient, and we use the machines more consistently. Or at least the machines where time counts matter the most are on all the time.
You’ve found it, or very nearly. The very next section is Expires:
> The format is an absolute date and time as defined by HTTP-date in Section 3.3.
The implication is subtle but critical. When the server sends a Date header and an Expires header, you don’t expire the content when the local time exceeds the Expires Header. You expire it at
LocalTime + (Expires - Date)
That covers not only time zones but also clock drift. When the client is sending data such as a POST, it also sends a Date header. That can account for time zones, clock drift, and to an extent network latency. When you’re legally bound to establish the order of events in a distributed system someone has to be the source of truth, and even when you’re not it’s still good to have for your own purposes. The system of record is the only thing that is running on the same clock as the system of record, so it is the most sensible source of truth.
So when a client sends you a buffer full of dated events, you can (and should) consider the timestamps in the POST body as relative to the Date header, not your local system time. Otherwise someone running on brown power or old school power saving mode will screw up all of the timelines in your data.
Not as wonky as you'd think, and 60 minutes means something much different than 12:15. Which can be good and it can be bad, but many of my experiences with TTLs have not been pleasant. 60 minutes, as typically implemented, means some user out there has data that is 1:58 stale and he's yelling at your boss on the phone who is now trying to figure out if he should be passing the favor along.
See also ETags which stop trying to be clever about dates and instead be clever about the contents of the message.
Why I like the Date header is that it works well with REST endpoints that care about time but for whom caching is either not a good idea or is orthogonal.
> Not as wonky as you'd think, and 60 minutes means something much different than 12:15.
The expression you’ve posted is literally a complicated way of writing 60mn, and you specifically wrote that it should not be interpreted as 12:15.
> See also ETags which stop trying to be clever about dates
Etags have unrelated role and semantics. Etags go with last-update, which doesn’t suffer from anywhere near as much from drift because it’s checked by the server, which emitted it.
Applications that are require clock synchronization across multiple machines should be maintaining their own clock anyways, independent of the system clock. NTP for millisecond-order precision, atomic clock time cards for microsecond-order precision.
The cost is that conversion to/from civil time is far more complicated, and worse, cannot be computed for future dates for which leap seconds have not yet been determined.
Skipping or smearing leap seconds means conversion to/from civil time is simple ... as long as you only want an accuracy of +-1 second.
If you need better conversion, you have to know how the system chose to handle leap seconds. If it smears, you have to know and implement the smear algorithm, if it doesn't then some unix timestamps will map to two different points in civil time (second 59 and 60 in any hour with a leap second).
For 99.9% of applications, it's not a bad tradeoff. But if we're willing to fudge time by up to a second, recording time in TAI (just count a second every second) and living with future dates sometimes being off by a couple seconds when converted to UTC isn't that different in terms of utility/usability tradeoff, and conceptually simpler.
If you need better precision, you don't go converting to/from civil time, because people think on quanta of ~1 second and better precision is not defined there.
Instead, I'll put my rule here: It's perfectly reasonable to drop your time precision to ~1 second when converting it into "people time", and you should never expect better precision from a back conversion.
That's not saying you don't need TAI. It's just not reasonable to mix it and UTC et. al. If you need TAI, you live in TAI.
How many times a second do computers communicate notions of time between each other, versus to a human? We’re talking many orders of magnitude here, and inequalities like that always change the winning strategy.
Also the opening paragraph, paraphrasing "In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move."
≥ that represents a date around 292 billion years in the future, or roughly 22 times the estimated age of the universe, and thus officially Somebody Else's Problem.
And another... (Also, given Adams wrote a few Dr. Who episodes, one which turned into Life, the Universe and Everything, the "Time Lords" reference could be another.) The "Oh, and one more thing" is a slight misquote of, "And another thing."
As DNA is my favorite author bar none, I like this post a lot.
> (Also, given Adams wrote a few Dr. Who episodes, one which turned into Life, the Universe and Everything, the "Time Lords" reference could be another.
Nice, a good point, well caught.
> As DNA is my favorite author bar none, I like this post a lot.
Me too.
Plug: join ZZ9. See the wonders of the universe, experience excitement, adventure and really wild things! https://zz9.org/
Worked for a company recently that does test equipment for timing and sync.
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.
> So GNSS systems have their own representation of time and the protocols that most network equipment uses is called PTP.
It's not so much that (Ethernet?) network equipment uses PTP, but rather to get the accuracies desired (±nanoseconds) there needs to be hardware involved, and that makes baking it into chips necessary. It's an IEEE standard so gets rolled into Ethernet.
Applications for PTP are things like electrical grid and cell network timings. Most day-to-day PC and server applications don't need that much accuracy.
Most office and DC servers generally configure NTP, which gives millisecond (10^-3) or tens/hunderds-microsecond (10^-6) accuracy. Logging onto most switches and routers you'll probably see NTP configured.
To get the most out PTP (10^-9) you need to generally run a specialized-hardware master clock.
"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 fraction of the time it takes a particular large rock to complete a full rotation around its own axis" 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.)
> 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. The unix time is synced with UTC. UTC has so called "leap seconds" scheduled at irregular intervals by the International Earth Rotation and Reference Systems Service to keep it in sync with the Earth's actual movements. So in effect the unix timestamp is wrangled to sync with the Earth's motion.
Thanks for the correction, this is quite important. I had taken statements that Unix and Posix time excludes or ignores leap seconds to mean that it increases monotonically in a continuous manner in sync with whatever atomic clock is the standard; on the contrary, it recognizes and implements leap-seconds with a discontinuity deviating from the steady tick of that standard.
I also learned that 00:00:00 UTC on 1 January 1970 is a proleptic time, as UTC was not in effect then, though I am not sure that makes it subject to subsequent planetary motions.
"Unix time numbers are repeated in the second immediately following a positive leap second. The Unix time number 1483142400 is thus ambiguous: it can refer either to start of the leap second (2016-12-31 23:59:60) or the end of it, one second later (2017-01-01 00:00:00)."
> Well, 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
Seconds have not ever been defined that way, because the time it takes for the earth to complete a full rotation around its own axis (the "sidereal day") was never a question of much interest. It's mostly relevant to astronomers.
Seconds were always defined in terms of the synodic day, the time it takes for a point on the earth that is aimed directly at the sun to rotate around the earth until it is once again aimed directly at the sun.
They still are defined that way, in the sense that the only purpose of other definitions is to match the traditional definition as exactly as possible. If cesium started vibrating faster or slower, we'd change the "official definition" of a second until it matched the traditional definition. Given that fact, which definition is real and which isn't?
That's an interesting point of view, but is it not the case that the length of the synodic day varies throughout the year, on account of Kepler's 2nd. law? - IIRC, this is the first-order effect in explaining the analemma. The length of the sidereal day is also variable, but more slowly (at least if we put aside atmospheric and earthquake effects, which I guess affect both equally.)
I think we need both a way to reckon our everyday experience of passing time and a constant measure, and one cannot be just a special case of the other. Personally, I feel that introducing leap seconds into Unix time just muddied the waters.
As to the sidereal day being of little interest outside of astronomy, James Watt's patron/partner Matthew Boulton built a sidereal clock and tried hard to find a purchaser (even having it shipped to Catherine the Great in hopes of sparking some interest) without success. It was on display in his Birmingham home when we visited a few years ago.
> but is it not the case that the length of the synodic day varies throughout the year, on account of Kepler's 2nd. law?
I don't see the relevance; the length of the sidereal day isn't constant either.
Variation in the length of the synodic day is the reason a day may contain other than 86400 seconds. If days are not of constant length, you could vary the length of a second on a day-to-day basis, or you could define the length of a "reference day" and then define the second as a convenient fraction of that. We have taken the second approach (though the first was used historically).
But we don't care about the vibration of cesium; if that were to change, we would adjust by changing the definition of a second, not by accepting that seconds were now of a different duration than before. Thus, the fact that cesium is referenced in an "official" definition of the duration of a second is meaningless. The officialness of that definition is illusory; in reality, seconds continue to be defined as a convenient fraction of an average day.
> Variation in the length of the synodic day is the reason a day may contain other than 86400 seconds.
Indeed; so when the second was defined by a fraction of a day, that day was an abstraction which approximates any given synodic day. I take your point that the author's quoted statement was incorrect, as the synodic day is a function of the earth's orbital period as well as its rotational one.
I also take your point that we don't care about a specific transition of a cesium atom per se, but I am not so sure that any more than a rather small fraction of the population care that a second is 86400 of what was an average day at some point in time (even though it is is a good approximation for today's days.) What fraction, I wonder, have ever performed a calculation on seconds using that number, other than, perhaps, for pedagogical purposes? Other than that, is it not just a convenient short interval where its constancy (a property that cesium delivers better than does the Earth's motions) is paramount? One might point out that such calculations are frequently done on their behalf, but from that perspective, the recent large increase in the use of GPS, with its heavy computational demand that is dependent on the constancy of atomic clocks, should equally be taken into account.
> so when the second was defined by a fraction of a day, that day was an abstraction which approximates any given synodic day
Commenting separately for this - I'm not sure it's true. To my understanding, the historical European division of the day was that the day contained 12 hours of equal length, and the night contained 12 other hours of equal length. They were obviously familiar with the fact that the day and the night were themselves not equally long, so an hour of day and an hour of night would almost never have been equal durations.
This willingness to vary the length of an hour over the course of a year suggests that it probably wouldn't have been a problem to vary the second along with it.
I had heard that of the ancient Greeks, though Wikipedia gives the origin more vaguely as the ancient Near East. It is a practical way of thinking when you are outdoors most of the time, you are not very active at night, and a sundial is your timekeeper. It also helps to be at a relatively low latitude, where the seasonal variation is not so great.
This makes sunrise and sunset the important moments in daily timekeeping, and this is, of course, the case in the Jewish definition of a day (I would not be surprised to learn that Jewish scholars also worked with intraday fractions of the lunar cycle.)
If this did lead to a willingness to vary the second along with the length of the hour, this would seem to me to argue against the specialness of the definition of the second as 1/86400 of the mean synodic day. I doubt, however, that anyone but perhaps a few scholars at that time ever contemplated such a small division of time. The second only became a practical measure with the development of accurate mechanical clocks, by by then, mean time had largely taken over sundials and other forms of intraday ephemeris timekeeping, as that is what mechanical clocks measure. (This transition, I suspect, had a greater impact on the general population than did the adoption of the atomic standard, if only because the latter had no practical impact.) At that point, the second was defined by sexagisimal division of the hour (and thus, obviously, transitively as a fraction of a particular mean synodic day, given the definition of an hour in such terms.)
> I am not so sure that any more than a rather small fraction of the population care that a second is 86400 of what was an average day at some point in time (even though it is is a good approximation for today's days.) What fraction, I wonder, have ever performed a calculation on seconds using that number, other than, perhaps, for pedagogical purposes?
It would be unusual to make a calculation directly using the factor of 86,400 between seconds and days.
But people make calculations using the conversion factors of 60 seconds per minute, 60 minutes per hour, and 24 hours per day all the time. If you have those, you can't avoid the conversion factor of 86,400 seconds per day.
You can't deny the implication, but whether that elevates it to a position of special relevance is another matter, at least as I see it. Personally, unless I have been thinking about it recently (which is very rarely), I would have to do the calculation before answering the question of how many seconds are in a day (and if I were being more than usually pedantic, I would have to ask "which day?")
In my view (which, admittedly, is somewhat subjective), people are not even tacitly concerned with the number of seconds in a day unless they are contemplating the number of seconds in an approximately day-length or longer period. On the other hand, I can imagine some of my relatives, who were conservative in all matters almost by reflex, responding to the SI definition by saying something like "Nonsense! there are sixty seconds in a minute, sixty minutes in an hour, and twenty-four hours in a day, and that's that!" - once they had learned something, it was set in stone. I am pretty sure that the annual variability of the synodic day was not among the things they had learned, and the idea of a leap second would be deeply troubling.
I appear to have talked myself into agreeing with you that 60.60.24 is what matters to most people by default, as they don't know the minutiae of celestial timekeeping or the increasing importance of atomic timekeeping (let alone relativity!) in their everyday lives.
That’s a very recent change - and it’s not like 9192631770 transitions/hz (which is hilariously self referential!) is some obvious, natural value that ISN’T based on the historic ‘typical’ length of the day based on our rotation around the sun.
A second being 1/86400th of a day (24 hrs * 60 minutes * 60 seconds per minute) is still essentially true, and based, essentially still on the seasons and our movement around the sun (or relative movements between the various bodies in the solar system, depending).
Being a chaotic natural system, we of course need to add fudge factors here and there to simplify the math day to day while keeping it aligned with observed reality, like leap seconds and all), at least where it intersects with reality in a material way.
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.
Shamelessly I'll here remind people to never use gettimeofday() to measure time. E.g. setting the time backwards used to cause any currently running "ping" command to hang. (they fixed it about 10 years after I sent them a patch)
It comes from a natural inclination of I want something to expire some period from now.
The natural way is to say what time is it now. Figure out what time you want to expire with a date add. Then busy wait until that time expires using some form of gettime. The very big assumption you make is that the gettime methods always move forward. They dont.
This bug is easy to make thinking you are treating a wait item as a calendar event. Its not. You need to find something to busy wait on, that always counts up. Do not use the system clock. Also pick something that counts at a known fixed rate. Not all counters are equal. Some can skew by large margins after an hour and triggering when you do not expect. Which makes people want to reach for the system clock again. If you somehow decide 'i will use the clock' be prepared for some pain of the dozens of different ways that fails.
A long time ago -- late 1980s -- I worked in system software, VMS-based, at DEC.
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.
Are our key tech vendors doing the same now? It'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.
I know redefining time_t with 64 bits "solves" the problem. But only if it gets done everywhere. Anybody who's been writing programs for more than about 604 800 seconds has either thought through this problem or hasn't.
Mongodb, for one, will freak out if you set the system date into the future, interact with it, then set time back. It will think the indices are corrupt and refuse to start. At least that happened to me last year. IIRC, the time stamp is part of generated object ids, so it’s sort of understandable. In the end I returned by computer to the future date, exported data, and rebuilt my collections.
I’m curious whether there is any database that handles this scenario correctly…or even whether there is a correct behavior for a situation where the system clock is rewound.
Good question. I used to test an auction app I maintained on SqlServer but I never pushed it more than a few hours into the future. To be clear: my experience with MongoDb was a one off local issue. No idea if there are server protections etc.
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.
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.
Putting on my pedantic hat though, I see that East and West were switched in the discussion of Japan's unique 50/60Hz AC frequency split, and I can'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.
If you still have such a machine (preferably without any valuable data), try setting the date right before the overflow with this command
date -s @$[2**31 - 10]
and see if you can recover the system without reboot.
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.
A digression: The documented bash syntax for arithmetic expansion is $(( EXPRESSION )) . I see that $[ EXPRESSION ] also works, but I don't see it documented anywhere. (Both syntaxes also work in zsh.)
Factories are full with machines that get replaced every couple decades, and that run software setups even older. Roughly a decade ago I was involved in the development of an embedded system for industrial use, and the approach to Y2038 was "doesn't matter, I'll be retired by then". The system is still sold.
I wouldn't be surprised if a lot of companies will handle it by just setting the clocks back 50 years or so on industrial equipment. But God have mercy on those that forget some systems.
Most of these systems probably don't even care about the real time... so it'd just be more effective to map them back to a different index and handle it with an offset externally.
At a glance it looks like 1971 and 1993 might be good alternatives for 2038. The command line cal program agrees with where dates start each month for all three years.
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:
- 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.
UTC is a vague approximation of UT1 using TAI and a leap seconds data source similar to tzdata.
On most modern CPUs, there is an accurate monotonic counter. The problem though is it doesn't know anything about when it was started or when it went to sleep in any time system.
Oh and bugs. Some systems interpret edge cases in one way, and others in others. Academic purity, interoperability: pick 1.
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.
Daylight savings time rules change. Timezones change. And then you get tzdata.
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 "conversion code" so that you only deal with "seconds". Timezones, leap seconds... all of that only matters when you're showing the user a date. For recording and calculations, it doesn't.
> Take the Traders’ method of timekeeping. The frame corrections were incredibly complex—and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth’s moon. But if you looked at it still more closely… the starting instant was actually about fifteen million seconds later, the 0-second of one of Humankind’s first computer operating systems.
Excerpt From A Deepness in the Sky by Vernor Vinge
Unix time is UTC based, so it ignores leap seconds and deviates from how many seconds actually passed since the start of the epoch.
The actual number of seconds passed corresponds to TAI, but you can't convert future timestamps from TAI to UTC since you can't predict leap seconds, so you can't display future TAI timestamps using typical date notation.
> For recording and calculations, it doesn't.
Depends on what you're recording and calculating. Storing a UTC timestamp generally works when recording an event that already happened.
But it doesn't work for scheduling events like meetings, since there the authoritative time is often local time. If you simply store such future events in UTC you'll run into problems when the definition of the relevant timezone changes.
You can easily "display future TAI timestamps using typical date notation".
Both past timestamps and future timestamps are not exact numbers, but approximate numbers, affected by errors.
The only difference between past timestamps and future timestamps that are converted from TAI to UTC is in the magnitude of the errors.
If the past timestamps have been acquired on a computer whose clock had been synchronized by NTP, then the errors are likely to be less than 10 millisecond.
If the past timestamps have been acquired on a computer whose clock had not been synchronized with a precise source, then the errors are likely to be greater than a second and they may be as large as of several minutes.
For future timestamps, the uncertainty of the value of the difference between TAI and UTC makes the likely value of the errors to be of several seconds, and increasing with the distance of the timestamp in the future.
In conclusion, one must be aware of the probable magnitude of the errors affecting an UTC timestamp, but that does not prevent conversions between TAI and UTC, whenever that is desired.
One of the greatest mistakes when dealing with time values is handling them like they were exact values, which they are not.
To handle future timestamps with minimal errors, it is necessary to have 2 distinct data types, a TAI time expressed as a number of some time units, e.g. nanoseconds, and an UTC time that is a structure containing date and time of the day. An UTC time must never be expressed as a number of seconds from some past date. That is the huge mistake made by the "UNIX time".
Future timestamps must be stored using the appropriate data type, e.g. UTC time for a future scheduled meeting.
The hardware clocks and the low-level clock synchronization and handling programs should always use TAI time.
When the current time approaches a future UTC timestamp, the error of the estimation of the corresponding TAI time diminishes. The leap seconds are announced with many months in advance, so the correct TAI time for a future UTC timestamp will also be know with at least a few months in advance. There is no risk that you computer will fail to notify you about the right time of the meeting, except when a naive programmer handles the timestamps wrongly, which is unfortunately quite frequent.
Unix time is not UTC-based. It counts the number of seconds passed since a certain point in time, which may be described as date and time expressed in any time zone you like. It just so happens that in UTC it is easiest to remember for a human what this point was, since you get a lot of zeroes at the end.
Edit: I’m not entirely correct here, as aside from UTC the time zone, there is also UTC the time standard. See below.
I stand corrected. As I’ve double-checked now, unfortunately “UTC” is ambiguous in that it may refer both to the time standard and the time zone. In this case one can say that Unix time is based on UTC the time standard, but not the time zone. Although given that in Unix time every day has the same number of seconds and instead the clock is sometimes slowed down, while in UTC there is an additional 61st second, can we truly say that it’s UTC-based? I’d say it’s its own standard derived from UTC. Maybe that’s being too pedantic.
> Timezones, leap seconds... all of that only matters when you're showing the user a date. For recording and calculations, it doesn't.
You cannot, by definition, tell how many Unix seconds later "third of may, 2025, at noon, local time" is - there is no way to convert future, local times to Unix times, because that "conversion code" is not fixed. Sure, we can reasonably expect that definition of time flow relationship to local time will not change for past dates, but one must expect these changes for times in the future.
Not really. Generally, you can tell whether "fifth of November, at midnight, local time" is equal to `now` or not as long as you have reasonably accurate information what "local" means. This is a problem of time encoding, because we do define what midnight is, but keep relationship between it and seconds passed undefined as long as possible
And you can do that when "now" is encoded as unix time as well, provided you know what local is. Although, encoding "now" is by definition pointless, since "now" changes with every instant.
Is there a system that does allow you do to do this? I can't think of one that would.
Local time requires a time zone, times zones are defined in relation to UTC, and there is an unknown number of leap seconds between now and 3 May, 2025.
Yes and no. The thing is that it is quite convenient to track time in computers with monotonic clocks, but it also turns out that humans do not define time markers based on monotonic clocks (when far future times are considered) and just from time to time [re]define relationship between time markers and monotonic clocks.
By definition you cannot unambiguously tell how many seconds in the future Christmas in a few years will be. However, it turns out that as long as you have the monotonic clock synced, time marker definitions up to date and have reasonably accurate understanding what local time means you can rather easily tell whether `now` is "christmas in 3 years, when defined at 123456789 Unix time".
We, humans, define time markers based on astronomical phenomena relative to this particular floating rock. A system based on time markers (calendar days, holidays, full moons, whatever) can represent human times, but is very inconvenient for computers, because they are not necessarily well-defined. I mean, 12345679 Unix time is well-defined in itself even if it is not well-defined in relation to real world while "2025 May 3rd at noon" is simply not well-defined today. Timekeeping is extremely weird.
This is a trade-off. Either you store computer consumable time markers (monotonic clock values), but have to do processing to figure out how they relate real-world markers, or you store real-world markers and have to do processing to figure out how they relate to the monotonic clock. Sans DST, the first one is much more ergonomic.
DST is pain, but turns out it is pain in both systems. If you have future time marker and there is DST adjustment between `now` and `then` you have the very same problem: you don't know whether DST adjustment was taken into account when creating the marker. Fun thing is that if you do control (or can infer) adjustments, both systems become very similar, but the current is much more ergonomic.
UNIX timestamps are horrible. You can not do calculations with them, with fractional part they do not sort correctly, and you actually can not reliably convert them back and forth to iso timestamps. Basically to do anything useful, you need additional bit carried along the timestamp to tell if its leap second or not, which is extremely awkward and most APIs do not support that.
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.
Haven't astronomers already found a way to solve this problem? by using the standard Epoch.
"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."
[https://en.wikipedia.org/wiki/Epoch_(astronomy)]
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.
We’re only about 60-70 years into the age of computing and have no idea how long legacy software systems will truly last. Also imagine uses cases like exploratory or orbiting spacecraft which might have useful shelf lives into the triple digits.
It’s bad planning because 64-bit time stamps were supposed to provide coverage for “22 times the expected lifetime of the universe”, but by being the only OS to use those 64 bits to count nanoseconds, they only bought a couple more bits over 32-bit timestamps. What they could have done differently is not used nanoseconds for the epoch counter. Milliseconds seem like they would have offered the perfect balance.
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.
… 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. …
—Robert Grudin, Time and the Art of Living.
[1] https://www.gnu.org/software/coreutils/manual/html_node/Date...