Just stick with TAI and convert times to UTC when displaying them is required. The real crap here is the C and POSIX time_t type and its related functions, which are massively out of date (like the 70% of the C standard library). The ISO C standard committee is way too scared of breaking stuff, and when they add something is often utter garbage (look at the whole _s functions fiasco in C11).
> Just stick with TAI and convert times to UTC when displaying them.
That may not be suitable when you want to represent an exact point in time years into the future. You’re usually not interested in the exact number of elapsed seconds (TAI) in that case, but want to represent e.g. 2031-08-03T:00:00:00Z exactly.
The solution is to use different data types for elapsed time and for calendrical/time-of-day time. Software developers need to learn that those are not equivalent, and libraries, databases etc. need to provide appropriate data types that make the distinction clear.
If you want an UTC time in the distant future, more than a few years away, then you cannot know how much time will pass until then.
The leap seconds are inserted randomly, you cannot predict when this will happen.
The UTC time is known only for the past, more precisely for the past 60 years.
For the future beyond a year, the UTC time is unknown.
On the other hand TAI, which is a real time, not a conventional quantity determined by political decisions, is known both for the past and for the future.
You are right that e.g. for scheduling meetings in the future, a different type must be used, whose meaning is "the time moment that will have this official name by then". This time should not be used for computing time differences with a resolution smaller than a day, before it becomes close enough to the present.
I think you're misunderstanding the proposal. Civil time (UTC) is still known well in the future, just as well as TAI is known well in the future. It is the relationship between them that is unknown.
The problem with rendering TAI as UTC is you can't do it for future dates because you don't know how many leap seconds will have been added by then. For future dates you can either:
- store TAI: you'll always know how many SI seconds in the future it is, but you won't be able to accurately render UTC,
- store UTC timestamp: you'll always know what the time on the clock will be when the event happens, but you won't be able to accurately calculate how many seconds in the future it is.
The alternative is to ditch UTC. Make all wall clocks tick in SI seconds and render TAI dates in local time. This will always be correct. The only downside is you won't be able to accurately predict what position the Sun is in the sky when the event happens. But is this actually important?
Another problem here is that DST is political, and under local political control. Politicians don't get why changes in timscales have to be announced well in advance; there have been cases where they were announced as little as a month before they came effect.
Some commenters seem to wonder why people care about the relationships between timescales, and how to convert between them. Well, contracts seems to be a good example. It could be vitally important to know, to the second, when a 200-year-old contract came into force.
Yes... this way leads to madness. Time seems to be in a special class of problems that is easy to get wrong and hard to get right. I think we just have to aim for "least wrong" and try to keep our sanity intact.
if you want the future time stamp to be “exactly x seconds” in the future you can store a tuple of the TAI time stamp of when you create the data point, and the SI seconds into the future from that time and then render it as appropriate for the audience’s level of understanding
And if you want the future time stamp to be not actually a time stamp but a time of day on a calendar date, then you store a tuple of the TAI creation time, the UTC date you want it to be in the future
Because you can never ever be sure of the future, by keeping the time you make the assumptions you can at least either calculate the correct answer or fix the data later when you find out something has changed.
They should be scared of breaking stuff! If newer standards break things, those newer standards are unlikely to get wide adoption, which prevents actual progress.
In any case, while the POSIX and C standards need to accommodate atomic time, that's not enough. The software on top needs to switch to atomic timestamps too.
C++ is being adding basically both the kitchen and the sink for years now and still it hasn't broken anything. If anything, lots of warts have been removed now. This whole reasoning doesn't hold when the ISO C standard adds half-assed, optional rubbish to the C standard only to deprecate it the next release.
The ISO C can't create a newer, saner C string library or a more useful time library, but it finds the time to devise and release crap like VLA, threads.h or _s functions. Meanwhile, C++20 has stabilized std::chrono::tai_clock, which works on all major operating systems, and does not break anything.
There's plenty of good additions in C and bad additions in C++. (Also I object to the assertion that VLAs are bad! They are an improvement to function signatures.)
> I object to the assertion that VLAs are bad! They are an improvement to function signatures.
The main issue is that they are not restricted to that. They went overboard and basically made alloca() part of the language, causing all kinds of bugs when a newbie (or a senior, too) mistakenly uses variables instead of defines for an array size.
If they were just an annotation, it would not have been complaining, even though they would still remain quite unusable in practice due to C++ not supporting them (that's why they're seldom used in public headers).
