UTC, Tai, and Unix Time (2001)(cr.yp.to)
cr.yp.to
UTC, Tai, and Unix Time (2001)
https://cr.yp.to/proto/utctai.html
146 comments
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.
TAI is an absolute time based on atomic vibrations. UT1 is a relative time based on astrometric systems.
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.
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.
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.
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.
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.
I thought that was the plan when they decided to give up on leap seconds.
I don't get the insistence on keeping nominal seconds-alignment (or even minutes-alignment) between the clock and the sun's position; we already don't experience it in practice.
Timezone regions are fudged all over the world[1] for political and practical reasons, but even if they weren't, people living near one timezone edge don't experience the "sun noon" at the same time as people living near the other edge, even though they share the same clock time.
[1] just look at the map here: https://en.wikipedia.org/wiki/Time_zone
I don't get the insistence on keeping nominal seconds-alignment (or even minutes-alignment) between the clock and the sun's position; we already don't experience it in practice.
Timezone regions are fudged all over the world[1] for political and practical reasons, but even if they weren't, people living near one timezone edge don't experience the "sun noon" at the same time as people living near the other edge, even though they share the same clock time.
[1] just look at the map here: https://en.wikipedia.org/wiki/Time_zone
It has nothing to do with time zones. People can deal with weird time keeping practices, but distributed software systems can become completely borked. It's happened before in all sorts of different ways. Transaction order can get messed up. Event queues can drop or duplicate events. Obviously, it's a big problem, otherwise people wouldn't be so intent on getting rid of them. And having a leap hour instead of a leap second would be a whole order of magnitude worse, especially if it occurs after hundreds or thousands of years of people writing software that's oblivious to the phenomenon.
But completely getting rid of leap seconds for UTC is misguided. We already have TAI, which is literally just UTC without leap seconds. If leap seconds are messing with your system, just use TAI. Don't make UTC a slightly worse version of TAI.
I feel like I'm taking crazy pills.
But completely getting rid of leap seconds for UTC is misguided. We already have TAI, which is literally just UTC without leap seconds. If leap seconds are messing with your system, just use TAI. Don't make UTC a slightly worse version of TAI.
I feel like I'm taking crazy pills.
> I feel like I'm taking crazy pills.
Civil society around the world has decided on UTC as the basis for time. What’s easier, convincing everyone to switch to TAI or changing the definition of UTC? I would guess it’s the latter.
Civil society around the world has decided on UTC as the basis for time. What’s easier, convincing everyone to switch to TAI or changing the definition of UTC? I would guess it’s the latter.
> It has nothing to do with time zones. [...] And having a leap hour instead of a leap second would be a whole order of magnitude worse [...]
The idea is exactly to not have a leap hour, UTC is kept completely untouched. Everyone changes their timezone instead, exactly like we already do with daylight savings, except this would happen only once every few thousands of years instead of twice a year.
The idea is exactly to not have a leap hour, UTC is kept completely untouched. Everyone changes their timezone instead, exactly like we already do with daylight savings, except this would happen only once every few thousands of years instead of twice a year.
Well the current plan according to the BIPM is to keep adjusting UTC, but with bigger and less frequent adjustments. I'm predicting they'll change course in a hundred years, as you say, and just give up on leap seconds/minutes/hours altogether. So yes, I agree that this is the most likely scenario.
But again, we already have a time system that does not have leap seconds/minutes/hours. TAI and UTC would become effectively redundant. I don't understand why we need another version of TAI.
But again, we already have a time system that does not have leap seconds/minutes/hours. TAI and UTC would become effectively redundant. I don't understand why we need another version of TAI.
I agree with everything you said, I just don't see why we need both UTC and TAI. That is, I don't understand why we insist on keeping UTC synchronized with Earth's orientation.
On the one hand (like you said before), UTC is what we use for stuff like ordering transactions, which has absolutely nothing to do with the position of the Sun in the Sky.
And on the other hand, we already use timezones to reconcile the rough position of the Sun with our universal clock. Timezones only have resolution of 1 hour (or half in very few places), but looking at how fudged a lot them are, people don't really seem to care. I mean, look at Argentina, which fits almost perfectly in UTC-4 but chooses to use UTC-3 instead. China is even crazier, using a single time in its whole territory which could easily have 3 or 4 different timezones.
On the one hand (like you said before), UTC is what we use for stuff like ordering transactions, which has absolutely nothing to do with the position of the Sun in the Sky.
And on the other hand, we already use timezones to reconcile the rough position of the Sun with our universal clock. Timezones only have resolution of 1 hour (or half in very few places), but looking at how fudged a lot them are, people don't really seem to care. I mean, look at Argentina, which fits almost perfectly in UTC-4 but chooses to use UTC-3 instead. China is even crazier, using a single time in its whole territory which could easily have 3 or 4 different timezones.
At it's core, UTC is about reconciling 2 different clocks; the Earth (basically represented by UT1) and the Cesium atom (represented by TAI). It's a useful basis for Civil time -- which is naturally political -- because everybody seems to intuitively agree that seconds should be defined by the Cesium standard but days should be aligned with the Earth's rotation. It's not guaranteed that all governments would pick the same if forced to pick only one of the two. That would make time zones even harder.
Sure, people in Western China may regularly see the sun at midnight, but that's not without controversy. People generally like the sun to be out when they're up.
So I think it makes sense to have both UTC and TAI. If the BIPM just turns UTC into TAI plus a constant offset, then I'd wager they would eventually introduce another system to take the place of the former UTC, with leap seconds, so some people can have that system that reconciles the two clocks if they want it. It's hard to predict the future. But the reasoning in the GCPM resolution [1] seems inherently flawed to me. "recalling that the CGPM at its 26th meeting (2018) ... stated that UTC is the only recommended time scale for international reference" is the core of the problem. TAI should be the ultimate basis. UTC is based on TAI (with leap seconds), and civil time based on UTC.
[1]: https://www.bipm.org/en/cgpm-2022/resolution-4
Sure, people in Western China may regularly see the sun at midnight, but that's not without controversy. People generally like the sun to be out when they're up.
So I think it makes sense to have both UTC and TAI. If the BIPM just turns UTC into TAI plus a constant offset, then I'd wager they would eventually introduce another system to take the place of the former UTC, with leap seconds, so some people can have that system that reconciles the two clocks if they want it. It's hard to predict the future. But the reasoning in the GCPM resolution [1] seems inherently flawed to me. "recalling that the CGPM at its 26th meeting (2018) ... stated that UTC is the only recommended time scale for international reference" is the core of the problem. TAI should be the ultimate basis. UTC is based on TAI (with leap seconds), and civil time based on UTC.
[1]: https://www.bipm.org/en/cgpm-2022/resolution-4
> I feel like I'm taking crazy pills.
I always told our new-hires to avoid thinking too deeply about computer timekeeping if they value their sanity.
I always told our new-hires to avoid thinking too deeply about computer timekeeping if they value their sanity.
Time can only be measured by clocks (oscillatory systems). It's a slippery concept for which humans have a natural, flawed intuition. But if you understand your clock(s) really well, then timekeeping makes perfect sense. There's just a lot of clocks around. There's Unix time, UTC, TAI, smeared UTC, stop-the-clock UTC, UT1, and lots of others. Make sure you understand the clocks your system is using and how they relate to one another, and you can keep your sanity.
Glad to see that this is being understood now.
https://news.ycombinator.com/item?id=28047376
https://news.ycombinator.com/item?id=29926509
https://news.ycombinator.com/item?id=28047376
https://news.ycombinator.com/item?id=29926509
> 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
> B. Each smaller time unit is of a fixed physical duration
This just gave me Timecube flashbacks
[deleted]
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).
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.
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.
Actually, this sort-of describes "smeared UTC", which is used by some computer systems such as Google's NTP servers: https://developers.google.com/time/smear
POSIX time does not generally work that way. It may seem that way for 1-second resolution timestamps, but at higher resolutions (say millisecond resolution), the clock does not completely stop. It keeps going, jumps backward 1 second, then continues.
POSIX time does not generally work that way. It may seem that way for 1-second resolution timestamps, but at higher resolutions (say millisecond resolution), the clock does not completely stop. It keeps going, jumps backward 1 second, then continues.
I think you're talking about struct timespec, I'm talking about time_t.
I don't think "POSIX time" specifies behavior during leap-seconds for the functions that return timespecs (gettimeofday() [0] and clock_gettime(CLOCK_REALTIME) [1]), so any behaviour would be valid - including smearing or repeating nanoseconds?
[0] https://pubs.opengroup.org/onlinepubs/9699919799/functions/g...
[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/c...
I don't think "POSIX time" specifies behavior during leap-seconds for the functions that return timespecs (gettimeofday() [0] and clock_gettime(CLOCK_REALTIME) [1]), so any behaviour would be valid - including smearing or repeating nanoseconds?
[0] https://pubs.opengroup.org/onlinepubs/9699919799/functions/g...
[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/c...
Doesn't it only pick C? Negative leap seconds make POSIX time skip a second.
POSIX time_t still ticked, but the interval between the ticks was 0s, rather than 1s or 2s.
It preserves A (exactly 86400 ticks per calendar day) and C (remains in alignment with UTC) by abandoning B (each tick has a fixed duration)
It preserves A (exactly 86400 ticks per calendar day) and C (remains in alignment with UTC) by abandoning B (each tick has a fixed duration)
One could also make ticks on such a day last 86400/86401 or 86400/86399 seconds, keeping the tick duration fixed but only for a given day (a relaxed version of B)
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...
https://robotsinplainenglish.com/e/2022-11-20-stopwatch-time...
> 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...
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...
> 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
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
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.
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.
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.
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.
This is true. However:
- You can subtract two SI-based timestamps to get a SI-based time difference. This will give you the correct number of nanoseconds.
- You can subtract two UTC-based timestamps to get a UTC-based time difference. This will not give you a number of nanoseconds.
Note that, if you have a list of when leap seconds are, then you can convert between SI-based and UTC-based timestamps which are counted from the epoch; in this way it is possible to get a SI-based time difference from UTC-based timestamps if you need it.
It is not as simple as just subtracting them of course, but if your application is meant to use precise time differences then you can just use SI-based timestamps instead of UTC-based timestamps, so that you can simply subtract them from each other. Programs that need to deal with days and calendars instead, are likely to prefer to use UTC-based timestamps instead.
- You can subtract two SI-based timestamps to get a SI-based time difference. This will give you the correct number of nanoseconds.
- You can subtract two UTC-based timestamps to get a UTC-based time difference. This will not give you a number of nanoseconds.
Note that, if you have a list of when leap seconds are, then you can convert between SI-based and UTC-based timestamps which are counted from the epoch; in this way it is possible to get a SI-based time difference from UTC-based timestamps if you need it.
It is not as simple as just subtracting them of course, but if your application is meant to use precise time differences then you can just use SI-based timestamps instead of UTC-based timestamps, so that you can simply subtract them from each other. Programs that need to deal with days and calendars instead, are likely to prefer to use UTC-based timestamps instead.
[deleted]
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
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
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.
Are they really? I wonder why this wasn't bigger news. Anyway that's good to hear.
> 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!
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!
No. UTC with leap seconds isn't "reality" except in the sense that some of those awful scripted "reality TV" shows are reality. It's a confection, and it's annoying so there's no real argument for it beyond "That's what we've always done" which is a pretty dubious rationale for anything, but even more so when it's been like that for less than a normal human lifespan.
Leap seconds won't even be like the automobile, let alone newspapers or hotdogs, they're a fleeting idea we thought might be good, now we realise it's not good, so bye bye.
There are two "realities" here. TAI is the monotonically increasing "Seconds are the same length and happen in order" clock time that it turns out well suits a lot of human enterprises. The exact details have been worked out pretty well. A Day in TAI is 24 hours of 60 minutes of 60 SI seconds, always, forever.
UT1 is a descendant of "Solar time" now based on the Earth's rotational angle. A Day in UT1 is the full rotation, how long that is in SI seconds varies very slightly and arbitrarily.
UTC wants to have the steady monotonicity of TAI except it wants to match UT1's days exactly, this is not a thing, so the "leap seconds" are conjured to kludge it. This kludge is what's going away, it's not part of "reality" it's a kludge to try to fit a square peg in a round hole and we're giving up the kludge.
It has been a long time since humans worked purely from direct observation of the "solar time" or rotation. Once the clock gets invented, so millennia ago, that's out and humans are measuring (albeit not very precisely at first) what we now call TAI. Giving up leap seconds is us finally accepting that while UT1 is astronomically interesting, it's not actually a sensible basis for day to day living.
Leap seconds won't even be like the automobile, let alone newspapers or hotdogs, they're a fleeting idea we thought might be good, now we realise it's not good, so bye bye.
There are two "realities" here. TAI is the monotonically increasing "Seconds are the same length and happen in order" clock time that it turns out well suits a lot of human enterprises. The exact details have been worked out pretty well. A Day in TAI is 24 hours of 60 minutes of 60 SI seconds, always, forever.
UT1 is a descendant of "Solar time" now based on the Earth's rotational angle. A Day in UT1 is the full rotation, how long that is in SI seconds varies very slightly and arbitrarily.
UTC wants to have the steady monotonicity of TAI except it wants to match UT1's days exactly, this is not a thing, so the "leap seconds" are conjured to kludge it. This kludge is what's going away, it's not part of "reality" it's a kludge to try to fit a square peg in a round hole and we're giving up the kludge.
It has been a long time since humans worked purely from direct observation of the "solar time" or rotation. Once the clock gets invented, so millennia ago, that's out and humans are measuring (albeit not very precisely at first) what we now call TAI. Giving up leap seconds is us finally accepting that while UT1 is astronomically interesting, it's not actually a sensible basis for day to day living.
> UTC with leap seconds isn't "reality"
Weeks aren't reality. Timezones aren't reality. Julian/Gregorian calendar months aren't reality. But they are essential.
Calendars, centralised time, and timezones drive coordinated human socialisation and commerce, increasing the wealth of all nations.
Countries have switched timezones so that their "work day" matches another more prosperous country's "work day"
Humans want, and have always wanted, a compromise between their activities, and the unalterable reality of nature. We have "daylight savings time" because if we say "work is between 9AM and 5PM", that allows for the synchronised commerce - you can phone another business at 9AM because you both start work at 9AM, and 9AM = 9AM for both of you. But the reality is that in the winter months, everyone is going to work or leaving work in darkness, with no daylight time for socialisation. So you shift your entire country's (or state's) offset from an absolute clock, to turn "9AM to 5PM" into "8AM to 4PM" without actually stating that, because if businesses started varying their hours, they'd desync completely and you'd never get business done again.
It hasn't been that long since we accepted centralised time, only really since the invention of railways, and especially since the invention of the telegraph. Prior to that, local solar time ruled. Bram Stoker was particulary upset that Ireland was 25 minutes out of alignment with Great Britain (Dublin Mean Time vs Greenwich Mean Time), in his view Ireland was missing out on a lot of trade [0]
I don't think we're going to move to a time source that will slowly desync us from nature. If we liked being desynced from nature, we've have ditched DST by now - we haven't. And we also haven't gone entirely back to nature and made it 9:30 in Dublin when it's 9:55 in London. I think we're going to remain on this middle path - fudging the mixture of atomic time and alignment with solar time - for the rest of our days on this planet.
[0] https://www.thefitzwilliam.com/p/turning-back-the-economic-c...
Weeks aren't reality. Timezones aren't reality. Julian/Gregorian calendar months aren't reality. But they are essential.
Calendars, centralised time, and timezones drive coordinated human socialisation and commerce, increasing the wealth of all nations.
Countries have switched timezones so that their "work day" matches another more prosperous country's "work day"
Humans want, and have always wanted, a compromise between their activities, and the unalterable reality of nature. We have "daylight savings time" because if we say "work is between 9AM and 5PM", that allows for the synchronised commerce - you can phone another business at 9AM because you both start work at 9AM, and 9AM = 9AM for both of you. But the reality is that in the winter months, everyone is going to work or leaving work in darkness, with no daylight time for socialisation. So you shift your entire country's (or state's) offset from an absolute clock, to turn "9AM to 5PM" into "8AM to 4PM" without actually stating that, because if businesses started varying their hours, they'd desync completely and you'd never get business done again.
It hasn't been that long since we accepted centralised time, only really since the invention of railways, and especially since the invention of the telegraph. Prior to that, local solar time ruled. Bram Stoker was particulary upset that Ireland was 25 minutes out of alignment with Great Britain (Dublin Mean Time vs Greenwich Mean Time), in his view Ireland was missing out on a lot of trade [0]
I don't think we're going to move to a time source that will slowly desync us from nature. If we liked being desynced from nature, we've have ditched DST by now - we haven't. And we also haven't gone entirely back to nature and made it 9:30 in Dublin when it's 9:55 in London. I think we're going to remain on this middle path - fudging the mixture of atomic time and alignment with solar time - for the rest of our days on this planet.
[0] https://www.thefitzwilliam.com/p/turning-back-the-economic-c...
> Weeks aren't reality. Timezones aren't reality. Julian/Gregorian calendar months aren't reality. But they are essential.
And we ignore all of those in computer "system" clocks, and track them in a secondary local time layer, quite rightly. We should have handled leap seconds the same way.
And we ignore all of those in computer "system" clocks, and track them in a secondary local time layer, quite rightly. We should have handled leap seconds the same way.
> while UT1 is astronomically interesting, it's not actually a sensible basis for day to day living.
Hard disagree!
Allowing ones clocks to gradually drift from the behaviour of the Earth (which regulates our biological lives) is a mess. Once can compare the eventual correction that will be required akin to the shift from the Julian to Gregorian calendar and the problems that caused.
TAI was always there for those who needed it.
Hard disagree!
Allowing ones clocks to gradually drift from the behaviour of the Earth (which regulates our biological lives) is a mess. Once can compare the eventual correction that will be required akin to the shift from the Julian to Gregorian calendar and the problems that caused.
TAI was always there for those who needed it.
The drift (a second every ~1.5 years) is so small the accumulation is irrelevant to biological processes. 2000 years from now it does not matter that solar time has drifted ~an hour. Beyond "what people millennia ago used to do at 7 we do at when the clock says 8" not being a problem (assuming we even live similar lives) I'll be god damned if we can stop ourselves from changing zones and whether or not we'll observe DST this year for the next 20 years let alone what else we'll muck up in the next 2000.
TAI will still be there and needed by folks. UTC is stopping adding leap seconds in the future, not reverting back as if it never had any.
TAI will still be there and needed by folks. UTC is stopping adding leap seconds in the future, not reverting back as if it never had any.
> The drift (a second every ~1.5 years) is so small the accumulation is irrelevant to biological processes.
It is irrelevant until it is not: just ask Julius Caesar and Pope Gregory XIII.
> Beyond "what people millennia ago used to do at 7 we do at when the clock says 8" not being a problem […]
The difference of an hour does make a difference, as sleep researchers and chronobiologists keep pointing out every time a discussion on DST comes up (it is not just about the sudden time jump, but also about the actual time):
* https://www.frontiersin.org/articles/10.3389/fphys.2019.0094...
* https://sleepresearchsociety.org/wp-content/uploads/2022/11/...
* https://srbr.org/wp-content/uploads/2018/10/SRBR-Statement-o...
* http://www.chronobiocanada.com/official-statements
It is irrelevant until it is not: just ask Julius Caesar and Pope Gregory XIII.
> Beyond "what people millennia ago used to do at 7 we do at when the clock says 8" not being a problem […]
The difference of an hour does make a difference, as sleep researchers and chronobiologists keep pointing out every time a discussion on DST comes up (it is not just about the sudden time jump, but also about the actual time):
* https://www.frontiersin.org/articles/10.3389/fphys.2019.0094...
* https://sleepresearchsociety.org/wp-content/uploads/2022/11/...
* https://srbr.org/wp-content/uploads/2018/10/SRBR-Statement-o...
* http://www.chronobiocanada.com/official-statements
If a difference of an hour that's been there your entire life is noticeable, we should be able to observe that as a discontinuity of quality of life at time zone boundaries.
> It is irrelevant until it is not: just ask Julius Caesar and Pope Gregory XIII.
You're refferring to needing to reform the entire calendar but this doesn't make sense in context of me explaining that the calendar itself never needs to be reformed in the first place. That the sun was a few degrees different in the sky for Julius Caesar when a modern clock reads 3 PM in his time is not inherently a problem as Julius Caesar wouldn't have the same norms as you do in terms of what wall time is acceptable for waking/sleeping/eating/working/etc. E.g. 20,000 years from now if a clock reads 3 AM during midday it' not a problem as society will have had 20,000 years to adjust 12 hours vs your referenced calendar reforms that changed everything overnight.
> The difference of an hour does make a difference, as sleep researchers and chronobiologists keep pointing out every time a discussion on DST comes up (it is not just about the sudden time jump, but also about the actual time):
Again, you're missing the forest through the trees - though in two different ways here. The first is that it's a minute over someone's (long) life, so what impact we feel when we change time by an hour twice a year isn't relevant. The second is that society, over 2,000 years, does not need to change timekeeping itself to wake up when the clock says 8 instead of 7. If the change were to happen over a short period then sure, it's not really feasible for society to move up what wall time their breakfast is four times a year or something, but an hour a millenia isn't even something society needs to consciously worry about.
My point is not that we don't have a biological clock, it's that the effect of leap seconds on a human's biological clock are too small to affect it. One of your sources already says it's 15-20 minutes misaligned a day, why are you using it to argue 1 additional minute for your entire life is impactful? On the long term societal scale my point is society won't always agree we should wake up when the wall clock says 7 am. That norm changing shifting ~an hour 2,000 years is not a relevant concern for changing the way we keep time.
You're refferring to needing to reform the entire calendar but this doesn't make sense in context of me explaining that the calendar itself never needs to be reformed in the first place. That the sun was a few degrees different in the sky for Julius Caesar when a modern clock reads 3 PM in his time is not inherently a problem as Julius Caesar wouldn't have the same norms as you do in terms of what wall time is acceptable for waking/sleeping/eating/working/etc. E.g. 20,000 years from now if a clock reads 3 AM during midday it' not a problem as society will have had 20,000 years to adjust 12 hours vs your referenced calendar reforms that changed everything overnight.
> The difference of an hour does make a difference, as sleep researchers and chronobiologists keep pointing out every time a discussion on DST comes up (it is not just about the sudden time jump, but also about the actual time):
Again, you're missing the forest through the trees - though in two different ways here. The first is that it's a minute over someone's (long) life, so what impact we feel when we change time by an hour twice a year isn't relevant. The second is that society, over 2,000 years, does not need to change timekeeping itself to wake up when the clock says 8 instead of 7. If the change were to happen over a short period then sure, it's not really feasible for society to move up what wall time their breakfast is four times a year or something, but an hour a millenia isn't even something society needs to consciously worry about.
My point is not that we don't have a biological clock, it's that the effect of leap seconds on a human's biological clock are too small to affect it. One of your sources already says it's 15-20 minutes misaligned a day, why are you using it to argue 1 additional minute for your entire life is impactful? On the long term societal scale my point is society won't always agree we should wake up when the wall clock says 7 am. That norm changing shifting ~an hour 2,000 years is not a relevant concern for changing the way we keep time.
> The difference of an hour does make a difference, as sleep researchers and chronobiologists keep pointing out every time a discussion on DST comes up (it is not just about the sudden time jump, but also about the actual time)
Do any of these sleep researchers have anything to say about France using CET instead of GMT even though CET is about an hour off from their natural time? Or Spain being on CET despite being almost another hour off from France?
Furthermore, how long is it going to take for the accumulated leap seconds to add up to a full hour of time? My understanding is that it’s on the order of centuries. If humanity can maintain an industrialized civilization that’s capable of keeping track of leap seconds for that long, most of us won’t even be living on the earth by the time it makes any difference.
Do any of these sleep researchers have anything to say about France using CET instead of GMT even though CET is about an hour off from their natural time? Or Spain being on CET despite being almost another hour off from France?
Furthermore, how long is it going to take for the accumulated leap seconds to add up to a full hour of time? My understanding is that it’s on the order of centuries. If humanity can maintain an industrialized civilization that’s capable of keeping track of leap seconds for that long, most of us won’t even be living on the earth by the time it makes any difference.
> Do any of these sleep researchers have anything to say about France […]
Perhaps ask French Sleep Research and Medicine Society (Société Française de Recherche et Médecine du Sommeil):
* https://www.sfrms-sommeil.org
* https://esrs.eu/national-sleep-society/france/
See also Spain:
> Human rhythmicity is subjected to the workings of the internal circadian clock, but it is also influenced by environmental time (mainly the light-dark cycle) and social timing imposed by the official time at our location, as well as by our work schedule. When a misalignment among these times occurs, an internal order impairment appears, which affects our health. Western Spain (GMT+1/+2) and Portugal (GMT0/+1) share similar longitudes (sun time) but have different official times, and thus they provide a “natural experiment” to assess how this discrepancy affects circadian rhythmicity and sleep in people with no work duties (>65 years). Although sleep duration was not affected, the circadian rhythms in the Portuguese were more robust, especially during weekdays, while higher desynchronization tended to occur in the Spaniards. Once official time was corrected by GMT0, meals took place later in Spain than in Portugal, especially as the day progressed, indicating the possible deleterious effect on circadian system robustness when official time is misaligned with its corresponding geographical time zone.
* https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9404853/
Perhaps ask French Sleep Research and Medicine Society (Société Française de Recherche et Médecine du Sommeil):
* https://www.sfrms-sommeil.org
* https://esrs.eu/national-sleep-society/france/
See also Spain:
> Human rhythmicity is subjected to the workings of the internal circadian clock, but it is also influenced by environmental time (mainly the light-dark cycle) and social timing imposed by the official time at our location, as well as by our work schedule. When a misalignment among these times occurs, an internal order impairment appears, which affects our health. Western Spain (GMT+1/+2) and Portugal (GMT0/+1) share similar longitudes (sun time) but have different official times, and thus they provide a “natural experiment” to assess how this discrepancy affects circadian rhythmicity and sleep in people with no work duties (>65 years). Although sleep duration was not affected, the circadian rhythms in the Portuguese were more robust, especially during weekdays, while higher desynchronization tended to occur in the Spaniards. Once official time was corrected by GMT0, meals took place later in Spain than in Portugal, especially as the day progressed, indicating the possible deleterious effect on circadian system robustness when official time is misaligned with its corresponding geographical time zone.
* https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9404853/
A leap minute every few centuries makes much more sense than a leap second every few years. We have until our great-great-grandchildren to prepare.
> A leap minute every few centuries makes much more sense than a leap second every few years. We have until our great-great-grandchildren to prepare.
People can't get the regular changes of DST and February 29 correct, and you want them to get a one-off change right?
I'd rather 'inflict' change (semi-)regularly so people at least try to get things right and get some practice, as opposed to a Hail Mary pass/change in some distance future.
People can't get the regular changes of DST and February 29 correct, and you want them to get a one-off change right?
I'd rather 'inflict' change (semi-)regularly so people at least try to get things right and get some practice, as opposed to a Hail Mary pass/change in some distance future.
We already have rules that are much rarer and more impactful than leap minutes would be. For example on Feb 29th 2000 an entire extra day was inserted on a century, an event that only happens once every 400 years! It was a complete non-event and only time nerds remember that it happened.
In the case of a leap minute, the worst that can happen is that your clock is 1 minute out every couple of centuries. Doesn’t seem so bad and certainly much better than dealing with leap seconds every few years.
We don’t need to constantly rehearse for such an event, we can just do nothing and die without worrying about it.
In the case of a leap minute, the worst that can happen is that your clock is 1 minute out every couple of centuries. Doesn’t seem so bad and certainly much better than dealing with leap seconds every few years.
We don’t need to constantly rehearse for such an event, we can just do nothing and die without worrying about it.
It was a non-event because 2100 will actually be an "odd" one, divisible by four but not a leap year.
Every dumb implementation that looked at division by 4 got 2000 right.
Every dumb implementation that looked at division by 4 got 2000 right.
> People can't get the regular changes of DST and February 29 correct, and you want them to get a one-off change right?
Leap seconds are already rare enough that people can't handle them properly. Every time one happens the bug fixes from the last one have been undone.
Leap seconds are already rare enough that people can't handle them properly. Every time one happens the bug fixes from the last one have been undone.
That really is the motherload of technical debt.
This discussion really is highlining the cultural differences between software engineers and other engineering fields.
This discussion really is highlining the cultural differences between software engineers and other engineering fields.
Not really. Adding leap seconds at the end of years is inferior because a year is a human-scale duration.
Planning something “next year” is human-scale. Planning something “next century” is not human-scale because I won’t be alive then.
If we use leap minutes then most people will not see one in their lifetime, compared to everyone seeing multiple leap seconds in their lifetime.
Planning something “next year” is human-scale. Planning something “next century” is not human-scale because I won’t be alive then.
If we use leap minutes then most people will not see one in their lifetime, compared to everyone seeing multiple leap seconds in their lifetime.
But when that leap minute does eventually occur, it's going to cause havoc in all the systems that don't handle it. Which, let's face it, there are going to be a lot of. Either because they were never designed for it or else the relevant code paths were never actually tested.
You could broadcast a leap minute with a decade to prepare for it and most software would still be developed, used, and die off in the 90 years in between. It's better for 15% of relevant software to have to worry about something so consequentially minor than 100%.
That didn't work so well for y2k issues. Just this month there was an article about a woman that keeps getting id'ed as being 1 year old instead of 101 years old because of a y2k fix.
If we are still using the same calendar in 60000 years, and if the Earth's Sun is still so important that we have to adjust our watches, we can start to talk about a leap day.
Granted, this is some 100 times longer than our calendar has lived. And some 10 times longer than any human calendar. So, I suggest we postpone the issue a bit.
Granted, this is some 100 times longer than our calendar has lived. And some 10 times longer than any human calendar. So, I suggest we postpone the issue a bit.
Indeed, leap day, leap hour, leap minute, etc is a distinction without a difference because either way the solution is the same: do absolutely nothing and let future humanity decide how much drift it can tolerate.
And yet, they won't, or won't be able to.
Leap seconds allow leap second bugs to be fixed in one generation. Leap minute bugs need cross-generational debugging.
https://gavinhoward.com/2023/02/make-the-leap-second-first-c...
Leap seconds allow leap second bugs to be fixed in one generation. Leap minute bugs need cross-generational debugging.
https://gavinhoward.com/2023/02/make-the-leap-second-first-c...
Please no just let it drift
It is not just about programmers, it is just that the Earth is not considered an accurate enough clock anymore. We can do better with atomic clocks.
For day-to-day operations, we don't need the exact position of the sun in the sky, in fact, with time zones, we can be off by hours and still do business. Using the sun would be inconvenient anyways, as each location would need its own time. So for that, a few seconds is completely negligible.
Not many people care about the precise position of the sun in the sky as seen from an arbitrary location, so there is no real need to skew our overall more useful atomic clocks for this.
Maybe, in a distant future, people will need to update their time zones to catch up with what would be a noticeable shift, big deal...
For day-to-day operations, we don't need the exact position of the sun in the sky, in fact, with time zones, we can be off by hours and still do business. Using the sun would be inconvenient anyways, as each location would need its own time. So for that, a few seconds is completely negligible.
Not many people care about the precise position of the sun in the sky as seen from an arbitrary location, so there is no real need to skew our overall more useful atomic clocks for this.
Maybe, in a distant future, people will need to update their time zones to catch up with what would be a noticeable shift, big deal...
> It is not just about programmers, it is just that the Earth is not considered an accurate enough clock anymore.
Computers (and those who programme them) are there to serve humans (with a biology regulated by the Earth), not the other way around!
Computers (and those who programme them) are there to serve humans (with a biology regulated by the Earth), not the other way around!
Human society screwed with biology in a big way since the industrial revolution. A few seconds, even minutes don't matter when business hours can disrupt sleep patterns of a significant part of the population by hours.
Terrestrial time don't serve society very well, as it is not very precise, it doesn't serve biology well either, as it is based on some arbitrary meridian instead of your actual location. Biology-compatible times would be in relation to sunrise and sunset, as it is sometimes done.
Terrestrial time don't serve society very well, as it is not very precise, it doesn't serve biology well either, as it is based on some arbitrary meridian instead of your actual location. Biology-compatible times would be in relation to sunrise and sunset, as it is sometimes done.
Leap seconds were accepted only because they were better than the previous solution (the "rubber second") and not enough people complained. It's just that we finally got enough complaints that they are being abolished. AND the end result is TAI being universally accepted, with a fixed offset due to the historical reason though :-p
Not programmers, the BIPM: https://www.bipm.org/documents/20126/64811223/Resolutions-20... Page 24 / Resolution 4
Input to BIPM to abolish leap seconds was overwhelmingly from the IT industry.
"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.
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.
If you stop pretending that universal time exists, then each timezone would need its own NTP stratum 0 atomic clock., Higher strata NTP servers would have to be told which timezone you wanted, and only return you the time sourced from whatever country's national labs count for that timezone, and those labs would not be allowed to compare each others times.
Each clock would run at a slightly different rate, based on imperfections in the equipment, the altitude of the laboratory and the amount of nearby mass in its vicinity. National clocks would drift, relative to each other, and so would everybody's timestamps. CET would be perhaps +1:00:00.000002 ahead of GMT rather than being exactly +1:00.
You'd have to continually measure and publish this drift in some kind of timezone-to-timezone comparison service, so that people who make network connections across the world don't end up finding that packets appear to arrive before they've been sent (due to National Clock drifts)
It's an interesting thought experiment. But I prefer where all the worlds' labs work together to produce a consensus universal time, and we just add fixed political offsets to it.
Each clock would run at a slightly different rate, based on imperfections in the equipment, the altitude of the laboratory and the amount of nearby mass in its vicinity. National clocks would drift, relative to each other, and so would everybody's timestamps. CET would be perhaps +1:00:00.000002 ahead of GMT rather than being exactly +1:00.
You'd have to continually measure and publish this drift in some kind of timezone-to-timezone comparison service, so that people who make network connections across the world don't end up finding that packets appear to arrive before they've been sent (due to National Clock drifts)
It's an interesting thought experiment. But I prefer where all the worlds' labs work together to produce a consensus universal time, and we just add fixed political offsets to it.
I like the odea of reference frames. But it isn't just geographic. The unix clock on a starlink is doing double digit mach and goes horizon to horizon in minutes. GPS satellites have always had to account for relativity, so we could look to that system... Hmm, seems gps time doesn't add leap seconds, only using those already added when it started ;)
Sure, you can define the reference frames to allow any orbit on any body. Mars landers & orbiters have slightly different time due to general & special relativity than Earth's surface, and also don't need Earth days/months/years, for example.
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.
Sidenote, "Tai" in the title should be TAI.
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.
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.
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).
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.
The kernel needs to maintain leap database for POSIX time too, so that it knows when to do those double-seconds
Typically operating systems don't maintain a database but instead rely on network time servers to let them know that a leap second is about to occur.
Not everyone has a network
The clock of machines is not reliable enough anyways most of the time. You end up having to reset them anyways.
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.
Yes, but most people are using POSIX time (intentionally or not). You don't need a database in POSIX time.
How does posix know it’s a leap second? It needs to know one way or another.
Some say it knows from a NTP server, but that’s the same as needing a database (the server has one)
Some say it knows from a NTP server, but that’s the same as needing a database (the server has one)
> How does posix know it’s a leap second? It needs to know one way or another.
Unlike with TAI it does not need to know. The time on the wall is leap seconds resolved (ignore for a second how it is done). Whereas TAI keeps ticking onwards without regard of them, UTC has them cleaned up. So if your end result is that you want to show a time in local time with TAI you need to know where all the leap seconds happened. With UTC you do not need to, you will have re-synchronized your clock plenty of times since to some time source which itself has resolved the leap seconds. You do not need NTP for this.
Even if you manually set your time once a year, you will use a reference source that has already dealt with the leap seconds. Since leap seconds are basically hidden historically too (they do not appear) you are good. You can always divide the seconds since 1970 down and you can pinpoint any date in the past without having to do complex leap seconds math.
Unlike with TAI it does not need to know. The time on the wall is leap seconds resolved (ignore for a second how it is done). Whereas TAI keeps ticking onwards without regard of them, UTC has them cleaned up. So if your end result is that you want to show a time in local time with TAI you need to know where all the leap seconds happened. With UTC you do not need to, you will have re-synchronized your clock plenty of times since to some time source which itself has resolved the leap seconds. You do not need NTP for this.
Even if you manually set your time once a year, you will use a reference source that has already dealt with the leap seconds. Since leap seconds are basically hidden historically too (they do not appear) you are good. You can always divide the seconds since 1970 down and you can pinpoint any date in the past without having to do complex leap seconds math.
[deleted]
That's no different to maintaining a timezone database though, and leap seconds are more coordinated than timezone changes.
I don’t need a timezone database to track UTC.
You do need it to do show that UTC value in local time, which most systems (except maybe server logs) eventually need.
And you still need leap seconds list for UTC.
And you still need leap seconds list for UTC.
What are you using as a time source, because I guarantee that source has said mapping (from TAI or GPS time or whatever timescale it actually getting the raw data for)?
UTC to a time people use / is legally mandated does not require knowledge of leap seconds as UTC takes care of it. So for all intents and purposes with UTC you can ignore that leap seconds exist.
TAI to a time people use requires knowledge of all leap seconds as you otherwise end up significantly desynchronized.
TAI to a time people use requires knowledge of all leap seconds as you otherwise end up significantly desynchronized.
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.
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.
It really doesn't matter if UTC drifts away from solar time by an hour every few thousand years.
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.
You could even align it with a DST transition in countries that have those where you simply skip one to apply the change.
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).
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
At that point, why not just move leap seconds entirely into local time as part of the time zone offset? Track each time zone’s initial, current, and (inevitable for at least some locales) final leap second offset. Include it directly in the numeric expression of the offset. Freeze UTC at the initial offset, update the relevant specs to provide for this, and call it effectively “done”, where “done” is that leap seconds are an entirely human-facing, local-jurisdiction-governed concern, entirely derived from monotonically incrementing base time.
Apart from backward compatibility, sounds like a good idea
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/
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/
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.
There will be no more leap seconds after 2035, AFAIK.
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.
The problem isn't really about handling local time. UTC is an offset from TAI and time zones are offsets from UTC, it's overall really just an offset from TAI. Coordinating the TAI-UTC offset is not any worse than coordinating time zone offsets.
The complications are around clocks, UNIX timestamp and NTP, where a steadily and monotonously increasing number would make the most sense, and that's not UTC.
The complications are around clocks, UNIX timestamp and NTP, where a steadily and monotonously increasing number would make the most sense, and that's not UTC.
Good news, the 2038 Unixtime mess should give some impetus on cleaning this all up before then.
Also, if we don't get some calendar reform, by the year 17000, the northward (spring) equinox will be around February 23rd.
Leap seconds should be first-class instead.
https://gavinhoward.com/2023/02/make-the-leap-second-first-c...
https://gavinhoward.com/2023/02/make-the-leap-second-first-c...
Why are people downvoting this comment? Genuinely curious what's not to agree with here.
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.
Okay, what do you think is useful about leap seconds?
Without them, one can compare the eventual correction that will be required to bring our clocks back into line with the Earth (and our biology!) akin to the shift from the Julian to Gregorian calendar?
No, it would just require time zone changes, which already happen a few times a year which we already know how to deal with (the TZ db).
I'm not sure why you think I'm qualified to give a suitable answer to this.
Did you ask the person above to explain why they aren't useful?
Did you ask the person above to explain why they aren't useful?
Okay, fair enough. I'll elaborate. Here's why I don't think they're useful: leap seconds exist to align standard time with the sun. But humans are the only ones who care about sun alignment; computers don't. And the effect of leap seconds is so microscopic that it doesn't matter to humans, especially since the alignment is inexact anyway (solar noon is never at exactly 12:00 PM on any given day except at one particular line of longitude per time zone). For getting it roughly aligned, which is what humans care about, we already have time zones with fixed, rarely-changing offsets from UTC, which I am not proposing we get rid of.
Since leap seconds don't help for subjective human needs, and they _also_ don't help for computers, science, engineering etc. (if you care deeply about solar noon for some technical reason you should use something that tracks it more precisely than UTC anyway), I can't think of anything they _are_ useful for, except for saving our descendants thousands of years from now from having to change time zones when it drifts far enough to matter, which I think is a speculative and not very compelling reason.
I'd happily change my opinion if I heard a good reason for keeping them, so I object to claiming that this is "hubris".
Since leap seconds don't help for subjective human needs, and they _also_ don't help for computers, science, engineering etc. (if you care deeply about solar noon for some technical reason you should use something that tracks it more precisely than UTC anyway), I can't think of anything they _are_ useful for, except for saving our descendants thousands of years from now from having to change time zones when it drifts far enough to matter, which I think is a speculative and not very compelling reason.
I'd happily change my opinion if I heard a good reason for keeping them, so I object to claiming that this is "hubris".
> (solar noon is never at exactly 12:00 PM on any given day except at one particular line of longitude per time zone)
According to the 20. amendment the term of an US president starts at Noon, 20 Januar. Simply noon. The USA seems to interpret it as 12:00 ET and makes it ceremonial inauguration for that time, possibly also the transfer of powers. But solar noon on the steps of the Capitol seems to be at 12:18 ET, I researched back at the last inauguration.
This discrepancy seems to be a great premise for a legal thriller, a political thriller, or sadly for a conspiracy theory. The latter definitely has some fertile ground.
The americans should start using the Washington Monument as a solar clock for this ceremony, imo.
According to the 20. amendment the term of an US president starts at Noon, 20 Januar. Simply noon. The USA seems to interpret it as 12:00 ET and makes it ceremonial inauguration for that time, possibly also the transfer of powers. But solar noon on the steps of the Capitol seems to be at 12:18 ET, I researched back at the last inauguration.
This discrepancy seems to be a great premise for a legal thriller, a political thriller, or sadly for a conspiracy theory. The latter definitely has some fertile ground.
The americans should start using the Washington Monument as a solar clock for this ceremony, imo.
Thanks, that sounds quite reasonable to the untrained ear.
Just wanted to say I didn't downvote the original comment, I was only trying to guess about how others were perceiving it.
Just wanted to say I didn't downvote the original comment, I was only trying to guess about how others were perceiving it.
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.
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.
> Why were they invented and implemented?
Because one cannot ignore nature?
I suspect the vast majority of those programmers who have problems with leap seconds should really be using (and are unaware of) TAI.
Because one cannot ignore nature?
I suspect the vast majority of those programmers who have problems with leap seconds should really be using (and are unaware of) TAI.
>Because one cannot ignore nature?
Sure we can, in computing make abstractions that ignore nature all the time. As long as there's no issue (or no big issue) with them being out of sync, we're fine.
Besides there are few things natural about how we handle time, those are already big towers of abstractions on top of the movement of celestial bodies that simplify and sidestep a lot of subtleties.
Sure we can, in computing make abstractions that ignore nature all the time. As long as there's no issue (or no big issue) with them being out of sync, we're fine.
Besides there are few things natural about how we handle time, those are already big towers of abstractions on top of the movement of celestial bodies that simplify and sidestep a lot of subtleties.
The world doesn’t use TAI. If I’m making a train booking app and the train departs at 21:50 in Germany in the summer, it’s not departing at 21:50 TAI+2, it’s departing at 21:50 UTC+2. So you cannot avoid using UTC.
Programmers simply deal with the world as it exists. Every single country uses UTC therefore that is how time must be represented. It is easier to remove leap seconds from UTC than it is to make all countries adopt TAI at the same instant.
The concept of leap seconds can of course be preserved by defining a new time standard that isn’t called “UTC”.
Programmers simply deal with the world as it exists. Every single country uses UTC therefore that is how time must be represented. It is easier to remove leap seconds from UTC than it is to make all countries adopt TAI at the same instant.
The concept of leap seconds can of course be preserved by defining a new time standard that isn’t called “UTC”.
TAI is ‘a second always takes the same amount of time, and the number of seconds is always increasing’. Which is really useful in the real world when tracking/counting events every second all the time.
Because leap seconds cause weird gaps or overlaps (depending on how they are happening).
This doesn’t matter for pretty much anyone who doesn’t track/log/act every second all the time in a way where if a second ‘disappears’ or happens twice or takes longer on one day than on another it’s noticeable.
When monitoring or tracking large scale systems, it’s a really irritating problem, which is why TAI is nice and exists in computer land. Also why it’s nice for many scientist types.
For everyone else, something like UTC layered on top is more than good enough. Leap seconds are fine enough there. Same with most timezones, and PDT/PST, etc.
Because leap seconds cause weird gaps or overlaps (depending on how they are happening).
This doesn’t matter for pretty much anyone who doesn’t track/log/act every second all the time in a way where if a second ‘disappears’ or happens twice or takes longer on one day than on another it’s noticeable.
When monitoring or tracking large scale systems, it’s a really irritating problem, which is why TAI is nice and exists in computer land. Also why it’s nice for many scientist types.
For everyone else, something like UTC layered on top is more than good enough. Leap seconds are fine enough there. Same with most timezones, and PDT/PST, etc.
The comment justifies it no worse than how the Fence principle is justified
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.
Anyway, that's an explanation of my opinion. Many people will disagree with it.
> Saying "oh we'll shift all the time zones around one day" isn't an acceptable solution as far as I'm concerned.
Why not? Time zones change constantly. Dealing with changing time zones is something we already know how to do easily.
Why not? Time zones change constantly. Dealing with changing time zones is something we already know how to do easily.
I don't think it's true that "changing time zones is something we already know how to do easily". At least not with the word "easily" in there. Time zones cause a lot of problems, which is why we don't change them constantly. And it would be nice to have a future in which time zones are changed even more infrequently rather than one in which they have to be changed to things like UTC-37:00 because they are specified in terms of a UTC that has become unmoored from the diurnal cycle of day and night.
But probably the main argument against getting rid of leap seconds from UTC is that we already have TAI for anyone who wants something like UTC but without the leap seconds. In fact we already have two things that are like UTC but without the leap seconds: there's TAI and there's also GPS time, offset from TAI by 19 seconds. If that's what you want, use TAI. Or use GPS. What's the points of adding a third kind of time that is just like those two but offset by yet another small constant offset?
I tend to think that there's a real use for something like UTC that stays in sync with the Earth's rotation (and thus with the diurnal cycle of day and night) and that if some coterie of bureaucrats turns UTC into another version of TAI/GPS then probably someone else will at some point have to invent another thing to replace UTC and then we'll be roughly back where we started just with extra confusing complexity.
Imagine you want to specify the date and time of an international online meeting. Today you'd probably use UTC for that. But if most of the world were more than 24 hours offset from UTC then using UTC would mean specifying the "wrong" date for the meeting. You probably wouldn't want to do that so instead you'd use whatever new thing has been invented to replace UTC, something that has leap seconds or leap minutes or leap hours (or leap days?) or some other way of staying in sync with the calendar. Leap seconds seems to me like the right granularity: they're small enough to be ignored for most everyday purposes, and frequent enough that programmers can't just pretend they don't happen.
(Sorry for the waffle ... I didn't intend to write that much. I should definitely care less about this seeing as whatever happens I'll be dead long before the shit hits the fan.)
But probably the main argument against getting rid of leap seconds from UTC is that we already have TAI for anyone who wants something like UTC but without the leap seconds. In fact we already have two things that are like UTC but without the leap seconds: there's TAI and there's also GPS time, offset from TAI by 19 seconds. If that's what you want, use TAI. Or use GPS. What's the points of adding a third kind of time that is just like those two but offset by yet another small constant offset?
I tend to think that there's a real use for something like UTC that stays in sync with the Earth's rotation (and thus with the diurnal cycle of day and night) and that if some coterie of bureaucrats turns UTC into another version of TAI/GPS then probably someone else will at some point have to invent another thing to replace UTC and then we'll be roughly back where we started just with extra confusing complexity.
Imagine you want to specify the date and time of an international online meeting. Today you'd probably use UTC for that. But if most of the world were more than 24 hours offset from UTC then using UTC would mean specifying the "wrong" date for the meeting. You probably wouldn't want to do that so instead you'd use whatever new thing has been invented to replace UTC, something that has leap seconds or leap minutes or leap hours (or leap days?) or some other way of staying in sync with the calendar. Leap seconds seems to me like the right granularity: they're small enough to be ignored for most everyday purposes, and frequent enough that programmers can't just pretend they don't happen.
(Sorry for the waffle ... I didn't intend to write that much. I should definitely care less about this seeing as whatever happens I'll be dead long before the shit hits the fan.)
It will take something like 5,000 years for solar time to drift from TAI by more than an hour. Given that time zones change a few times a year in random parts of the world (for example, eastern Kazakhstan changed from UTC+6 to UTC+5 to unify with the rest of the country this year), adding another occasion to change them every few thousand years makes no meaningful difference.
Your example of getting so far off that we have to change _days_ would take several times longer than the distance between the invention of agriculture and now. Honestly, I would be extremely surprised if human civilization survives that long, but even if it does, our descendants can just deal with the problem then. There's no reason to make our lives more difficult _now_ just to deal with this very niche hypothetical scenario.
Your example of getting so far off that we have to change _days_ would take several times longer than the distance between the invention of agriculture and now. Honestly, I would be extremely surprised if human civilization survives that long, but even if it does, our descendants can just deal with the problem then. There's no reason to make our lives more difficult _now_ just to deal with this very niche hypothetical scenario.
It's disappointing to see a well made argument like yours downvoted on HN.
Downvoting is meant for text that detracts from the conversation. Not as a tool for suppressing well made arguments one disagrees with.
Downvoting is meant for text that detracts from the conversation. Not as a tool for suppressing well made arguments one disagrees with.
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!"
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!"
> 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.
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.
That meaning is a human construction. It already doesn't mean where the sun is in the sky in the current location, it means in a single specific location per timezone. We could just agree that it means "where the sun is in the sky in Greenwich, UK"[1]
[1] Notionally. Obviously the sun is not often in the sky in London.
[1] Notionally. Obviously the sun is not often in the sky in London.
2 will continue causing confusion: "is it ok to schedule this for 1pm or is that too early in California?"
That already exists. It is my daily life in fact. eg "Is 8am PST too early for folks in IST?" literally is all day every day.
For example I literally have 3 emails in my inbox at the moment that arrived overnight from people in California saying some variation on "I saw a slot in your calendar for xpm PST, is that too late for you in London?".
For example I literally have 3 emails in my inbox at the moment that arrived overnight from people in California saying some variation on "I saw a slot in your calendar for xpm PST, is that too late for you in London?".
The set of people who care about anything that using one time zone for everyone would fix (mainly programmers who have to deal with time zone conversions) is much smaller than the set of people who care about the things it would break: anyone who wants to understand the shared global culture around local times (for example: anyone who travels to other time zones regularly, or even anyone who watches foreign movies or TV and wants to understand what the characters are talking about when they mention time of day).
That's why I support getting rid of leap seconds, but not getting rid of time zones: the number of people who leap seconds helps is very small (possibly zero) since their effect on everyday life is microscopic.
That's why I support getting rid of leap seconds, but not getting rid of time zones: the number of people who leap seconds helps is very small (possibly zero) since their effect on everyday life is microscopic.
Yeah I know. I'm not actually seriously entertaining the hope that 2 or 3 happen. Eliminating DST would be I think also be a genuine benefit to almost everyone with very little downside.
People are going to keep living their lives approximately according to local solar time, which means that the meaning of X time in practical terms ("is this a good time to call?") is going to be different from place to place, so people would need some way of looking up the normal schedule of a particular location. And now we've re-invented time zones but probably with slightly different details, meaning that we can't just re-use the old time zone tracking infrastructure as is.
> 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.
Good luck selling a large swaithe of humanity that Tuesday will turn into Wednesday at some point during their working day.
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.
We’ll burn that bridge when we come to it.
Quite offensive its characterisation of Posix, given RMS’ involvement to make GNU viable, as far as memory serves me.
[deleted]
Ultimately, I think nobody cares anymore about POSIX.
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.
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.
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.
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.