8 ms·

Can we take a longer hiatus on leap seconds, maybe 79 years or so, and only update once a century? Local apparent noon being off by 30 seconds or so has approxi

Can we take a longer hiatus on leap seconds, maybe 79 years or so, and only update once a century? Local apparent noon being off by 30 seconds or so has approximately zero impact on my daily life, but stupid things in datetime libraries do occasionally have impact. If we can’t throw off the oppression of UTC and greet TAI as liberators, at least adjust the clock at regular, very infrequent dates.

dgrin91 6y ago
Pretty sure there are lots of things that you use everyday that actually require precision time, such as GPS.
- im3w1l 6y ago
  As long as everyone agrees on the time GPS will work. It's a question of how much deviance from solar time we are willing to tolerate vs how much effort we want to tolerate.
- mormegil 6y ago
  GPS does not use leap seconds. See e.g. https://en.wikipedia.org/wiki/Global_Positioning_System#Leap_seconds https://en.wikipedia.org/wiki/Global_Positioning_System#Leap...
- bhk 6y ago
  Leap seconds have nothing to do with precision time. It's a non-periodic alteration to the definition of UTC. Those niche applications that require second-accurate knowledge of Earth's rotational accuracy don't need to rely on leap second changes to UTC; they could get that information out of band, and will need to anyway when they need sub-second accuracy. The 99.999% of other applications that don't need to know Earth's rotation orientation relative to the sun within a second -- but do have to calculate time differences between two UTC times -- would be much better off not having to deal with leap seconds. Leap seconds were a terribly misguided idea.
  - zokier 6y ago
    > Leap seconds were a terribly misguided idea. I prefer dropping leap seconds, but I wouldn't call them misguided. UTC and leap seconds come from maritime celestial navigation, where tracking rotation is actually important. Civil time then just piggybacked on that, which at the time probably was perfectly reasonable solution.
    - sla29970 6y ago
      A detailed look at the negotiations that led to leap seconds shows that they were not for maritime celestial navigation. During the process several different times the celestial navigation folks set a limit on how far radio broadcast time signals could deviate from astronomical time, and every one of those limits was violated as the negotiations proceeded. By the time the draft recommendation was given to 12th Plenary Assembly of the CCIR it allowed for leaps of multiple seconds, and that draft was amended on the floor to leaps of only one second before they voted to approve.
- Dylan16807 6y ago
  Precision isn't a binary, it's a continuum. The question at hand is whether there are significant use cases where 1 second of slack in matching the Earth's rotation is acceptable, but 30 seconds is too much. GPS isn't an example of that because 1 second is already a quarter mile off.
  - welterde 6y ago
    Pretty much all telescopes (under computer/time control) on this planet rely on UTC being quite close to UT1, since every second difference leads to a 15 arcsecond error in the pointing of the telescope (error between where you want to point the telescope on the sky and where you are actually pointing). While <5s is usually not a problem (except for some instruments with very very small FoV), at 30s it really becomes a problem for instruments with modest fields of view.
    - guenthert 6y ago
      I would think this is an argument for telescopes using UT1, not whether UTC should be adjusted for leap seconds. This is such a fringe application and all involved are aware of the issue, that I don't think it's relevant here at all.
      - welterde 6y ago
        UTC is defined to be within 1s of mean solar time at 0deg longitude (= UT1). If leap seconds are a problem for the intended application then UTC is the wrong thing to use. There are other scales that are defined differently that can be used in it's place (such as TAI). However if exact frequency is not critical one could also directly use UT1 instead of UTC (people that use leap second smearing for instance should have no issue with that..).
- Unklejoe 6y ago
  GPS time is already immune from leap seconds. It has a fixed offset from TAI of 19 seconds and always will. It also contains UTC offset information so that you can derive the current UTC time from GPS if you wanted to.
lifthrasiir 6y ago
I'm a diehard proponent of leap hours [1]. We already have a regular (or, rather irregular) adjustment in the civil time, namely time zones and "daylight saving" times. While I passionately hate DST, if we have to have DST anyway it's much better to make UTC adjustments use the same increment as well. [1] http://www.leapsecond.com/LEAPHOUR/ http://www.leapsecond.com/LEAPHOUR/
wyattpeak 6y ago
Besides the sibling comment that some things rely on the days being synced to rotation, doing it once a century would pretty much guarantee that only the most obsessively robust systems would take it into consideration when being built. We'd be giving ourselves a Y2k-equivalent to deal with every century. Maybe that's not the biggest deal in the world, but I still remember the last viscerally and we're already a fifth of the way to the next one (not to mention the timestamp bug one coming up in a decade). I disagree with the other comment's suggestion that leap hours can be taken into consideration like DST. I see no reason why DST code (which is generally implemented as an extra timezone) could straightforwardly be adapted to handle a single permanent shift of time.
- lifthrasiir 6y ago
  > I see no reason why DST code (which is generally implemented as an extra timezone) could straightforwardly be adapted to handle a single permanent shift of time. The point is that we don't have to add the additional code to handle leap hours, as it can be implemented as a large swath of time zone changes. We can imagine that there would be two versions of UTC, one before the leap hour (hereafter UTC) and one after the leap hour (hereafter UTC'). After the leap hour UTC and UTC' will coexist, where UTC' = UTC-1. Since time zone definitions themselves have UTC offsets, the trick is that instead of replacing all occurrences of UTC with UTC' (so that they would have UTC' offsets) we replace those offsets to have the same net effect. For example EST is UTC-5 before the leap hour and UTC'-5 = UTC-6 after the leap hour, so we pretend that the definition of EST changed to UTC-6. Note that this approach essentially fixes the UTC-TAI offset (as opposed to the UTC'-TAI offset) and makes UNIX timestamp (time_t) deviate from the current version of UTC (well, UTC'). I believe this is just a matter of definition and thus much doable than changing UTC every few year. After all, leap hours would be much rare, probably the first one would occur at least a few centuries later.
  - wyattpeak 6y ago
    The problem is not that changing the code is complicated. Changing code to accommodate four-digit years wasn't complicated. The problem is that you have to change every single piece of software which uses time. What you're proposing is exactly what I think needs to be avoided.
weinzierl 6y ago
> If we can’t throw off the oppression of UTC and greet TAI as liberators, at least adjust the clock at regular, very infrequent dates. Why not just use TAI for almost everything and leave UTC (including regular leap seconds) for applications that need it?
nemetroid 6y ago
The more infrequent your deployments, the more difficult they will be.
bloak 6y ago
People who can't cope with leap seconds should stop pestering the people who define UTC and just switch to TAI. They can do that now. No one is stopping them. Leap seconds are a pain and I myself would happily choose TAI over UTC for the system clock on a typical embedded system. However, for civil time keeping and for some technical purposes, UTC as currently defined is exactly what we need. Don't fuck with it.
- zokier 6y ago
  > However, for civil time keeping and for some technical purposes, UTC as currently defined is exactly what we need. Don't fuck with it. You are asserting that without any justification. I see no benefits and lots of downsides in having leap seconds in civil time specifically.
  - dfox 6y ago
    I think that the point is that for most definitions of "civil timekeeping" you just do what Unix does and ignore the leap seconds altogether and simply live with the fact that once in a while one wall-clock second takes two SI seconds (or does not exist at all), probably by simply being completely oblivious to that fact.
    - zokier 6y ago
      Don't even get me started on UNIX time. On that I agree with the parent comment, whatever the time scale, you shouldn't fuck with it. Alas, UNIX is what it is..
- btilly 6y ago
  No, they can't. Programmers have to deal with the outside world. The outside world has timezones defined as offsets from UTC. So when UTC changes, the whole world changes their clocks, and programmers have to cope. If your program doesn't agree with that world about what time it is, your program will get blamed. If it was a choice that I could individually make, I would tell astronomers to go pound sand. But it isn't. By historical happenstance, they have been put in charge of time, and it is truly a question of the tail wagging the dog when they care about a 1 second deviation between UTC and the position of the sun at a particular longitude.
sarah180 6y ago
Can we take this solved problem and replace it with a new one that has details we haven't figured out?
forgotmypw17 6y ago
How does TAI relate to Epoch time? More and more I use Epoch time for most things just because of how convenient it is. I rarely need sub-second granularity, and it's just one number, so it's sortable, math-able, etc. Then whoever is doing the display can convert it any way they want to.
- revicon 6y ago
  Remember that your code needs to account for the possibility of a negative leap second, meaning if you're using epoch time for timestamps you could have an instance that an event that happened after a previous one could be stamped as having happened before it instead. https://en.wikipedia.org/wiki/Leap_second https://en.wikipedia.org/wiki/Leap_second Edit: Actually I was slightly wrong, in the event of a leap second, we would repeat the same second twice.
  - forgotmypw17 6y ago
    Thank you for the heads-up! I try to write code loose enough that this would not be a problem. :)

dgrin91 6y ago

Pretty sure there are lots of things that you use everyday that actually require precision time, such as GPS.

im3w1l 6y ago
As long as everyone agrees on the time GPS will work. It's a question of how much deviance from solar time we are willing to tolerate vs how much effort we want to tolerate.
mormegil 6y ago
GPS does not use leap seconds. See e.g. https://en.wikipedia.org/wiki/Global_Positioning_System#Leap_seconds https://en.wikipedia.org/wiki/Global_Positioning_System#Leap...
bhk 6y ago
Leap seconds have nothing to do with precision time. It's a non-periodic alteration to the definition of UTC. Those niche applications that require second-accurate knowledge of Earth's rotational accuracy don't need to rely on leap second changes to UTC; they could get that information out of band, and will need to anyway when they need sub-second accuracy. The 99.999% of other applications that don't need to know Earth's rotation orientation relative to the sun within a second -- but do have to calculate time differences between two UTC times -- would be much better off not having to deal with leap seconds. Leap seconds were a terribly misguided idea.
- zokier 6y ago
  > Leap seconds were a terribly misguided idea. I prefer dropping leap seconds, but I wouldn't call them misguided. UTC and leap seconds come from maritime celestial navigation, where tracking rotation is actually important. Civil time then just piggybacked on that, which at the time probably was perfectly reasonable solution.
  - sla29970 6y ago
    A detailed look at the negotiations that led to leap seconds shows that they were not for maritime celestial navigation. During the process several different times the celestial navigation folks set a limit on how far radio broadcast time signals could deviate from astronomical time, and every one of those limits was violated as the negotiations proceeded. By the time the draft recommendation was given to 12th Plenary Assembly of the CCIR it allowed for leaps of multiple seconds, and that draft was amended on the floor to leaps of only one second before they voted to approve.
Dylan16807 6y ago
Precision isn't a binary, it's a continuum. The question at hand is whether there are significant use cases where 1 second of slack in matching the Earth's rotation is acceptable, but 30 seconds is too much. GPS isn't an example of that because 1 second is already a quarter mile off.
- welterde 6y ago
  Pretty much all telescopes (under computer/time control) on this planet rely on UTC being quite close to UT1, since every second difference leads to a 15 arcsecond error in the pointing of the telescope (error between where you want to point the telescope on the sky and where you are actually pointing). While <5s is usually not a problem (except for some instruments with very very small FoV), at 30s it really becomes a problem for instruments with modest fields of view.
  - guenthert 6y ago
    I would think this is an argument for telescopes using UT1, not whether UTC should be adjusted for leap seconds. This is such a fringe application and all involved are aware of the issue, that I don't think it's relevant here at all.
    - welterde 6y ago
      UTC is defined to be within 1s of mean solar time at 0deg longitude (= UT1). If leap seconds are a problem for the intended application then UTC is the wrong thing to use. There are other scales that are defined differently that can be used in it's place (such as TAI). However if exact frequency is not critical one could also directly use UT1 instead of UTC (people that use leap second smearing for instance should have no issue with that..).
Unklejoe 6y ago
GPS time is already immune from leap seconds. It has a fixed offset from TAI of 19 seconds and always will. It also contains UTC offset information so that you can derive the current UTC time from GPS if you wanted to.

lifthrasiir 6y ago

I'm a diehard proponent of leap hours [1]. We already have a regular (or, rather irregular) adjustment in the civil time, namely time zones and "daylight saving" times. While I passionately hate DST, if we have to have DST anyway it's much better to make UTC adjustments use the same increment as well. [1] http://www.leapsecond.com/LEAPHOUR/ http://www.leapsecond.com/LEAPHOUR/

wyattpeak 6y ago

Besides the sibling comment that some things rely on the days being synced to rotation, doing it once a century would pretty much guarantee that only the most obsessively robust systems would take it into consideration when being built. We'd be giving ourselves a Y2k-equivalent to deal with every century. Maybe that's not the biggest deal in the world, but I still remember the last viscerally and we're already a fifth of the way to the next one (not to mention the timestamp bug one coming up in a decade). I disagree with the other comment's suggestion that leap hours can be taken into consideration like DST. I see no reason why DST code (which is generally implemented as an extra timezone) could straightforwardly be adapted to handle a single permanent shift of time.

lifthrasiir 6y ago
> I see no reason why DST code (which is generally implemented as an extra timezone) could straightforwardly be adapted to handle a single permanent shift of time. The point is that we don't have to add the additional code to handle leap hours, as it can be implemented as a large swath of time zone changes. We can imagine that there would be two versions of UTC, one before the leap hour (hereafter UTC) and one after the leap hour (hereafter UTC'). After the leap hour UTC and UTC' will coexist, where UTC' = UTC-1. Since time zone definitions themselves have UTC offsets, the trick is that instead of replacing all occurrences of UTC with UTC' (so that they would have UTC' offsets) we replace those offsets to have the same net effect. For example EST is UTC-5 before the leap hour and UTC'-5 = UTC-6 after the leap hour, so we pretend that the definition of EST changed to UTC-6. Note that this approach essentially fixes the UTC-TAI offset (as opposed to the UTC'-TAI offset) and makes UNIX timestamp (time_t) deviate from the current version of UTC (well, UTC'). I believe this is just a matter of definition and thus much doable than changing UTC every few year. After all, leap hours would be much rare, probably the first one would occur at least a few centuries later.
- wyattpeak 6y ago
  The problem is not that changing the code is complicated. Changing code to accommodate four-digit years wasn't complicated. The problem is that you have to change every single piece of software which uses time. What you're proposing is exactly what I think needs to be avoided.

weinzierl 6y ago

> If we can’t throw off the oppression of UTC and greet TAI as liberators, at least adjust the clock at regular, very infrequent dates. Why not just use TAI for almost everything and leave UTC (including regular leap seconds) for applications that need it?

nemetroid 6y ago

The more infrequent your deployments, the more difficult they will be.

bloak 6y ago

People who can't cope with leap seconds should stop pestering the people who define UTC and just switch to TAI. They can do that now. No one is stopping them. Leap seconds are a pain and I myself would happily choose TAI over UTC for the system clock on a typical embedded system. However, for civil time keeping and for some technical purposes, UTC as currently defined is exactly what we need. Don't fuck with it.

zokier 6y ago
> However, for civil time keeping and for some technical purposes, UTC as currently defined is exactly what we need. Don't fuck with it. You are asserting that without any justification. I see no benefits and lots of downsides in having leap seconds in civil time specifically.
- dfox 6y ago
  I think that the point is that for most definitions of "civil timekeeping" you just do what Unix does and ignore the leap seconds altogether and simply live with the fact that once in a while one wall-clock second takes two SI seconds (or does not exist at all), probably by simply being completely oblivious to that fact.
  - zokier 6y ago
    Don't even get me started on UNIX time. On that I agree with the parent comment, whatever the time scale, you shouldn't fuck with it. Alas, UNIX is what it is..
btilly 6y ago
No, they can't. Programmers have to deal with the outside world. The outside world has timezones defined as offsets from UTC. So when UTC changes, the whole world changes their clocks, and programmers have to cope. If your program doesn't agree with that world about what time it is, your program will get blamed. If it was a choice that I could individually make, I would tell astronomers to go pound sand. But it isn't. By historical happenstance, they have been put in charge of time, and it is truly a question of the tail wagging the dog when they care about a 1 second deviation between UTC and the position of the sun at a particular longitude.

sarah180 6y ago

Can we take this solved problem and replace it with a new one that has details we haven't figured out?

forgotmypw17 6y ago

How does TAI relate to Epoch time? More and more I use Epoch time for most things just because of how convenient it is. I rarely need sub-second granularity, and it's just one number, so it's sortable, math-able, etc. Then whoever is doing the display can convert it any way they want to.

revicon 6y ago
Remember that your code needs to account for the possibility of a negative leap second, meaning if you're using epoch time for timestamps you could have an instance that an event that happened after a previous one could be stamped as having happened before it instead. https://en.wikipedia.org/wiki/Leap_second https://en.wikipedia.org/wiki/Leap_second Edit: Actually I was slightly wrong, in the event of a leap second, we would repeat the same second twice.
- forgotmypw17 6y ago
  Thank you for the heads-up! I try to write code loose enough that this would not be a problem. :)