UTC, Tai, and Unix Time (2001)

https://cr.yp.to/proto/utctai.html

by enz • 2 years ago

142 141 2 years ago

cr.yp.to

umanwizard9• 2 years ago

Leap seconds make no sense and we should just permanently stop doing them.

It really doesn't matter if UTC drifts away from solar time by an hour every few thousand years.

mihaic• 2 years ago

Why are people downvoting this comment? Genuinely curious what's not to agree with here.

AlecSchueler3• 2 years ago

I'd guess it's because it's the usual hubris, that a software engineer's loose thoughts are worth more than the wisdom of experts in the field. It writes off all the current work as simply useless without giving any defence of that position etc.

bloak2• 2 years ago

It's something people have strong opinions on. Obviously some people want to get rid of leap seconds but I personally like UTC with leap seconds. The only change I'd make is to require leap seconds to be announced several years in advance (which would require allowing a slightly bigger divergence between UTC and UT1). Computer systems should gradually migrate to using TAI internally, but a clock on the wall or a bus timetable should using something like UTC: something that, you know, stays in sync with the actual sun. Saying "oh we'll shift all the time zones around one day" isn't an acceptable solution as far as I'm concerned. And I don't believe leap minutes would work any better than leap seconds: in fact I'm fairly certain they would be a whole lot worse.

Anyway, that's an explanation of my opinion. Many people will disagree with it.

s_dev• 2 years ago

Chesterton's Fence. Why were they invented and implemented?

That has to be justified before scrapping something we don't necessarily understand and a lot of programmers are just grateful we have libraries to handle this complexity for us.

aragilar4• 2 years ago

I'd argue any system that's affected by leap seconds should be using TAI, and accepting that showing users the time (or accepting user input) is going to require an up-to-date table of conversions (it's not like a leap second is any bigger of a deal than the various changes to timezones).

mavhc2• 2 years ago

Exactly, we already store and show dates and times differently due to time zones, just add seconds to that alteration too. we have tzdb, add lsdb for leap second database and we can work out the difference for any time in the past, or near future

CryZe• 2 years ago

You are right, and whenever we drifted by 1 hour (or whatever is deemed too much) we can just update each time zone in the TZDB to be different by that amount of time going forward. This shifts the problem from a basically unsolved one (with how no OS properly supports TAI) to a solved one, time zones.

You could even align it with a DST transition in countries that have those where you simply skip one to apply the change.

tiagod• 2 years ago

Hopefully we get rid of DST in the next 1000 years...

seanhunter4• 2 years ago

With you on this. Also (in probably increasing order of controversy):

1)daylight savings should be completely abolished. It just causes confusion.

2)timezones should be completely abolished. They also cause confusion. If you live in California, instead of getting up at say 8am you get up at say 3pm. There is never any confusion with anyone globally about scheduling anything.

3)Months should be the same length. Instead of 12 months of 30, 31, 28 or sometimes 29 days, with a varying number of weeks in each month depending on the year, you have exactly 13 months of 4 weeks each (28 days). 13*28=364 which gives you an extra day "New years day" or "Christmas day" or whatever but that isn't a day of the week. If it's a leap year the day after that Christmas day is "Leap day" and it also isn't a day of the week. Then a particular date is always the same day of the week, months are all 4 weeks, quarters are exactly 3 months and 1 week each and have the same end dates every year etc. Tons of benefits.

Literally the only downside people come up with when I mention it is "yeah but imagine if your birthday is now a Monday, that would SUCK!"

darrenf• 2 years ago

2)timezones should be completely abolished. They also cause confusion. If you live in California, instead of getting up at say 8am you get up at say 3pm. There is never any confusion with anyone globally about scheduling anything.

But, err, "am" and "pm" refer to where the sun is in the sky. That's their literal meaning. It's useful information. Timezones are (obviously) a physical thing. Abolishing them to aide the comparatively tiny number of people worldwide who need to schedule a phone call with someone in another country is pretty bonkers IMO.

Furthermore, I don't want to be booking a flight home from Australia to the UK, pick a 9am departure from SYD only to discover it's in the evening.

eviks2• 2 years ago

2 will continue causing confusion: "is it ok to schedule this for 1pm or is that too early in California?"

growse• 2 years ago

2)timezones should be completely abolished. They also cause confusion. If you live in California, instead of getting up at say 8am you get up at say 3pm. There is never any confusion with anyone globally about scheduling anything.

Good luck selling a large swaithe of humanity that Tuesday will turn into Wednesday at some point during their working day.

planede3• 2 years ago

That's what TAI is for. Too bad nobody got the memo and everybody stores and communicates UTC, including computer clocks, UNIX time and NTP.

There will be no more leap seconds after 2035, AFAIK.

umanwizard9• 2 years ago

Sure. So my argument is that everything should use TAI, and local time zones should be an offset from TAI, not UTC (because local times are primarily for humans, and humans don't care about extremely slow time zone drift that leap seconds are designed to prevent). Then we can abolish UTC entirely since it serves no purpose.

fanf2• 2 years ago

The people in charge of leap seconds agree, and they are in the process of being abolished. The ITU World Radiocommunication Conference last year confirmed their part; the next stage is the CGPM in 2026.

https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-TF.2511-2022...

https://www.itu.int/hub/publication/s-gen-news-2023-2/

nabla9• 2 years ago

Leap seconds are eliminated from UTC by 2035.

umanwizard9• 2 years ago

That's great news.

rssoconnor• 2 years ago

Also, if we don't get some calendar reform, by the year 17000, the northward (spring) equinox will be around February 23rd.

gavinhoward2• 2 years ago

Leap seconds should be first-class instead.

https://gavinhoward.com/2023/02/make-the-leap-second-first-c...

aragilar4• 2 years ago

I'm surprised TAI isn't more widely used, given it hardcodes many of the assumptions programmers have about time.

Sidenote, "Tai" in the title should be TAI.

the_mitsuhiko5• 2 years ago

Is it really surprising? In practice people care about the time on the wall and to get that from TAI you need to maintain a leap second database.

aragilar4• 2 years ago

That's no different to maintaining a timezone database though, and leap seconds are more coordinated than timezone changes.

zokier2• 2 years ago

The kernel needs to maintain leap database for POSIX time too, so that it knows when to do those double-seconds

wodenokoto2• 2 years ago

Don’t you need that to calculate UTC as well? If you want to go back 30 seconds from 1st of January, 00:00:10 UTC, you need to know if the previous year had 60 or 61 one seconds in its last minute.

FObersteiner• 2 years ago

I guess we still like solar time a lot ;-) The point is, for date/time calculations, you need a numeric representation that increases strictly monotonically (an epoch time). If you introduce unpredictable modifications to that (leap seconds), the nice calculation falls apart, you end up with a lookup table such as the one in the IANA timezone database / TZif files (the blog post calls it the Olson library).

groestl• 2 years ago

That's because a lot of people have the misconception about UTC, that it works like TAI. If you think your tool already does what you like, even though it doesn't, you're not looking for anything else.

michaelt2• 2 years ago

That's because for a great many purposes, doing things the way everyone else does them is an extremely big benefit.

If your operating system uses UTC, your logging library uses UTC, your SSL cert issuer uses UTC, your TOTP tokens use UTC, your NTP client uses UTC, your e-mail headers use UTC, your string formatter uses UTC, your serialised data parsing libraries use UTC, everyone who sends you data uses UTC, and everyone you send data to wants to receive UTC - why swim against the current?

How do I know this? Because I've tried it. Let me assure you, for every bug you avoid using TAI, you'll experience 500 bugs due to UTC/TAI confusion.

re2• 2 years ago

Note that this page was written in 2001; the leap second situation has gotten a lot more complicated since then, with far more diverging implementations that handle it differently, and no real momentum towards widespread adoption of software that handles them "correctly" (explicitly), like the localtime() "fix" preferred by DJB.

Most people seem to prefer ignoring leap seconds, pretending they don't exist by "smearing" them across the surrounding day, or even getting rid of them entirely. https://news.ycombinator.com/item?id=33658541 https://news.ycombinator.com/item?id=32226414

planede3• 2 years ago

At least leap seconds will be eliminated by 2035, so there is that. Computers were never good at dealing with it. Keeping computer clocks in UTC instead of TAI and rewinding it for leap seconds was always insane. The same goes for UNIX time and NTP.

GJim9• 2 years ago

At least leap seconds will be eliminated by 2035

The arrogance of programmers who think it is possible to ignore reality to suit them :-)

I suspect the reality is many are unaware of TAI which would be more than 'good enough' and make life much easier for them.

EDIT: Downvotes simply for stating facts and opinions from outside the IT industry hardly prompts useful discussion!

schindlabua• 2 years ago

Are they really? I wonder why this wasn't bigger news. Anyway that's good to hear.

acqq• 2 years ago

"Smearing" is much more sensible approach for the use cases where it is implemented. There is simply no solution that is optimal for every use case, and insisting on using just one approach everywhere is unreasonable.

trwm• 2 years ago

We stop pretending that universal time exists and add location to every time stamp relative to some predefined clock at a known location. The issues of when something happened dissapear.

justin_• 2 years ago

UNIX time counts the number of seconds since an ``epoch.'' This is very convenient for programs that work with time intervals: the difference between two UNIX time values is a real-time difference measured in seconds, within the accuracy of the local clock. Thousands of programmers rely on this fact.

Contrary to this, since at least 2008[0], the POSIX standard (which is just paper not necessarily how real systems worked at that time) has said that "every day shall be accounted for by exactly 86400 seconds." That means that in modern systems using NTP, your Unix timestamps will be off from the expected number of TAI seconds. And yes, it means that a Unix timestamp _can repeat_ on a leap second day.

There's really no perfect way of doing things though. Should Unix time - an integer - represent the number of physical seconds since some epoch moment, or a packed encoding of a "date time" that can be quickly mapped to a calendar day? "The answer is obvious" say both sides simultaneously :^)

EDIT: I know DJB is calling out POSIX's choices in this article, but it seems like his "definition" does diverge from what the count actually meant to a lot of people.

[0] Also: "The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified." https://pubs.opengroup.org/onlinepubs/9699919799.2008edition...

zokier2• 2 years ago

There's really no perfect way of doing things though. Should Unix time - an integer - represent the number of physical seconds since some epoch moment, or a packed encoding of a "date time" that can be quickly mapped to a calendar day? "The answer is obvious" say both sides simultaneously :^)

Either way arguably POSIX time is the worst of both worlds, not being either of those. This is one of those cases where middleground compromise is worse than either option. Having datetime be just 15:17 bit structure (date:time_of_day) or more practically just int:int struct, it would be infinitely better than current POSIX time. Or just have it be plain SI seconds since epoch counter would also be better than POSIX time. Or even have both options available. There are so many better options, it is almost baffling how POSIX ended up with the worst possible one

zzo38computer3• 2 years ago

My opinion is to use a dual structure which is how I had considered in my operating system design: a signed 64-bit (or possibly longer) number of seconds, and a 32-bit number of nanoseconds (which is not always present; sometimes the precision of nanoseconds is unknown or unnecessary, so it would be omitted). There are then separate subtypes of timestamps, such as UTC (which allows the number of nanoseconds to exceed one billion) and SI (which does not allow the number of nanoseconds to exceed one billion). Which is appropriate depends on the application.

bloppe9• 2 years ago

That's an interesting approach, but not without pitfalls. You can't just subtract two timestamps to get a time difference, since there may have been one with 2 billion nanoseconds somewhere in between.

bloppe9• 2 years ago

I've spent literally hundreds of hours thinking about this, and I've landed on the opinion that TAI should always be the source of truth. It's usually not, because most systems ultimately get their source of truth from the GPS system, which uses something that looks kind-of like UTC (but is actually more similar to TAI, but people prefer to dress it up as UTC). This was a reasonable mistake that has caused so many problems due to the leap seconds.

If you're using TAI, it's more obvious that you have to account for leap seconds in order to convert to a human-readable civil time format (year, month, day, hour, minute, second). You know that you have to incorporate the official leap second list from IANA or some other authority. UTC makes it seem simpler than it actually is, and that's why there are so many problems.

You can always convert from TAI to civil time. You cannot always go the other way.

prmoustache2• 2 years ago

Ultimately, I think nobody cares anymore about POSIX.

zzo38computer3• 2 years ago

I am not sure about that. POSIX has some benefits, and its features are commonly used; however, there are also some problems.

There are other operating system specifications too, but I also wanted to make one operating system design, and I also wanted to avoid many of the problems with POSIX.

I did not konw that POSIX says that 2100 is a leap year, and clearly that is no good.

prmoustache2• 2 years ago

What I meam by that is 100% compatibility is not something we strive for anymore if parts/of it do not make any sense in 2024.

billpg• 2 years ago

Pick Two.

    A. A day is divided into a fixed number of smaller units.
    B. Each smaller time unit is of a fixed physical duration.
    C. The day cycle corresponds to the cycle of the solar day on Earth.

TAI picks A and B, allowing the solar cycle to drift from the time.

UTC picks B and C, adding leap seconds to keep track with Earth's solar day cycle.

UT1 picks A and C, redefining the "second" to the changing rate of earth's solar day cycle.

bxparks• 2 years ago

And I guess POSIX tries to pick all three, at least most of the time. It follows UTC mostly, except during leap seconds when it changes the duration of a POSIX-second to be 2 SI-seconds (positive leap second) or 0 SI-seconds (negative leap second).

amiga3865• 2 years ago

POSIX time_t picks A and C.

99.999998% of time_t ticks from 1970 until now have been 1 second long. 27 have been 2 seconds long. Therefore B ("each smaller time unit is of a fixed physical duration") is the variant.

dexwiz• 2 years ago

Another way to think about it is that UTC is a combination of UT1 and TAI. It’s kept within 1 second of UT1 and is always a fixed integer offset from TAI.

TAI is an absolute time based on atomic vibrations. UT1 is a relative time based on astrometric systems.

bloppe9• 2 years ago

It's not a fixed offset from TAI. The offset changes every time there's a leap second.

Also, there is no such thing as absolute time, because of relativity. We take pains to account for this by only measuring TAI on the Earth's geoid, but even so the uncertainty never reaches zero. Two "stationary" atomic clocks on the geoid are expected to drift by about a second every billion years or so. Sure, that's pretty good, but definitely no "absolute".

When you really think about it, the cesium atom and the earth's day/night cycle are both equally valid clocks. But the cesium atom measures time more similarly to the way we perceive time on a small scale. But, of course, our lives are scheduled based on the day/night cycle. So they both matter. UTC is the way we reconcile the two.

StableAlkyne• 2 years ago

A. A day is divided into a fixed number of smaller units.
B. Each smaller time unit is of a fixed physical duration

This just gave me Timecube flashbacks

bloppe9• 2 years ago

Ya, and Unix time decided they could fool people into thinking they had all 3, and as a result, every couple of years, time "jumps backward" by one second. It's hands down the worst option to use as the basis for a computing system that needs accurate timestamps, and it's made software developers really resent leap seconds.

Now the BIPM decided to "get rid" of leap seconds in UTC a couple years ago. I hope they come to their senses before 2035 when the change takes effect. Here's what will happen:

Rather than inserting a leap second every 1-2 years to keep UTC in sync with solar time, they plan to defer the problem to once every 100 or so years, and just insert like 50 leap seconds all at once. Think about that for a second. If leap seconds are so bad, how in the hell is the world going to deal with 50 of them at once after a century of oblivious complacency? They won't. They'll just say "Look, it's not worth it to have leap seconds in UTC anymore". Then, UTC will forever be just a constant offset away from TAI.

But we already have TAI. Why not just use TAI as your "source of truth", and let UTC be UTC? We'll have to introduce a new system to take the place of UTC and be in-sync with solar time; like how UTC used to be.

nemetroid2• 2 years ago

If we wait until UTC and UT1 differ by one hour, dealing with the adjustment will be no more difficult than dealing with time zones.

ripe• 2 years ago

Just came here to say that I like your explanation: succinct and correct. I am stealing it for my blog post.

https://robotsinplainenglish.com/e/2022-11-20-stopwatch-time...

FabHK• 2 years ago

Glad to see that this is being understood now.

https://news.ycombinator.com/item?id=28047376

https://news.ycombinator.com/item?id=29926509

vbezhenar• 2 years ago

TAI makes sense on Earth, but when it comes to separate cosmic bodies (like Moon base), my mind does not work well enough to understand how it would work, when time physically is different from the Earth time and even might change if we're talking about accelerating rockets. And how one would design a software and protocols exchanging instant values between those bodies.

lazide4• 2 years ago

We’ll burn that bridge when we come to it.

leandrod• 2 years ago

Quite offensive its characterisation of Posix, given RMS’ involvement to make GNU viable, as far as memory serves me.

UTC, Tai, and Unix Time (2001)

Related Stories