6 ms·

"Noon" is rooted in a physical phenomenon - when the sun is highest in the sky. But "UTC Noon" is arbitrary, because we had to pick a point on the earth. Leap

"Noon" is rooted in a physical phenomenon - when the sun is highest in the sky. But "UTC Noon" is arbitrary, because we had to pick a point on the earth. Leap seconds are trying to ensure that, standing at the point we arbitrarily picked for UTC at noon, the sun will be at its peak. That doesn't feel like something that NEEDS sub-second precision. I mean - by walking from one side of a time zone to the other, you can have an hour or more of imprecision. https://i.ibb.co/r000S5s/caxxyddlsgp11.jpg https://i.ibb.co/r000S5s/caxxyddlsgp11.jpg > Is there a single system currently in existence which can handle a leap minute? Every system can handle a leap-hour, they happen twice a year in many countries, courtesy of DST. So let's just wait until there's 15 minutes of error - a couple of millenia from now. Then move the UTC prime meridian about 3.75 degrees / 400km, fixing the error while keeping UTC monotonically increasing 1 second per second. And to update our clocks, use the one mechanism that we already rely on comfortably - timezones. Add 15 minutes to each timezone, the same way we handle DST now.

throw0101b 2y ago
> That doesn't feel like something that NEEDS sub-second precision. It does not need to be sub-second, but sub-seconds add up over time. The Julian calendar wasn't that far off, but it was cumulative, so to fix things it took a ten day jump: * https://en.wikipedia.org/wiki/Gregorian_calendar https://en.wikipedia.org/wiki/Gregorian_calendar It is considered easier to have a few small(er) semi-regular jumps than suddenly having to making giant, sudden, one-off jump in the future.
- skrebbel 2y ago
  We make small semi-regular changes to timezones all the time. DST switches, governments arbitrarily deciding that their country is going yo be in a different timezone (at a 2 day notice), or move the DST switch day by 2 weeks, etc etc. This is a solved problem and it happens all the time. The systems and datastructures that can deal with this (eg tzdata and the process & people behind it) are already in place.
  - throw0101c 2y ago
    > This is a solved problem and it happens all the time. UTC changing does not happen all the time: what the 'all the time' thing is a display/UI offeset against UTC. Time itself is not changed in those situations, but would be with a 'UTC jump'. The closest thing we get to universal time 'changing' are leap years and February 29, and we regularly get stories about people messing that up. And if something as common and regular as that gets fumbled I have little hope for pulling off a one-off jump of UTC. It is coördinating the universal part that I would imagine to be the difficult part.
    - skrebbel 2y ago
      Then just keep UTC when it is? (ie allow its prime meridian to shift away from Greenwich) Adjust all the timezones by half an hour in a few millennia. It’s really both fine and up to our grand-grand-grand-grand-etc-children to decide. Really, this is a non-problem.
      - organsnyder 2y ago
        > It’s really both fine and up to our grand-grand-grand-grand-etc-children to decide. I'd rather build gradual adjustments into our systems so that they have to be resilient to this sort of thing. Sure, leaving it up to our distant descendants is enticing, but then they're going to have a Y2K-sized problem to fix. I'd rather leave a legacy of systems that were designed to be resilient.
        School-Cotton 2y ago
        > then they're going to have a Y2K-sized problem to fix. No they aren't. tzdb updates happen several times a year already, and you don't notice.
        organsnyder 2y ago
        The suggestion I was responding to was to basically stop doing this.
- School-Cotton 2y ago
  It feels like you missed the main point. Time-zone changes are already very easy to handle and are sufficient for dealing with this problem without having to use a leap second or leap minute ever.
  - throw0101c 2y ago
    > Time-zone changes are already very easy to handle and are sufficient for dealing with this problem without having to use a leap second or leap minute ever. TZ changes are a display delta against UTC. The closest thing we get to universal time 'changing' are leap years and February 29, and we regularly get stories about people messing that up. If something as common as February 29 is fumbled, what are the odds of pulling a one-off event? And as someone who was a sysadmin when the US changed its TZ rules many moons ago, the sudden rule change was anything but straight-forward given the fairly static nature that they had been for the long history of software development that had occurred until that point: a lot of software is US-developed, and there was little/zero consideration to updating rules. (Though I think that event caused a lot of developers to be more understanding.)
    - afiori 2y ago
      In 400 years we can define new 30 minutes shifted timezones and in 400 - 500 years governments can slowly change their official timezones (maybe at summer/winter time they shift 30 minutes instead of 60). It does not feel like a big issue.
    - School-Cotton 2y ago
      The point is we don't need to change universal time. Thousands of years from now, when solar time drifts away from UTC enough for a particular country to care, that country can change its time zone. There doesn't need to be any global coordination and the process will be gradual enough that nobody will notice.
      - layer8 2y ago
        The EU already fails to agree on dropping DST (and adjusting time zones in the process), because member states will be affected differently, and neighboring countries that should really be in different time zones benefit from being in the same zone. I doubt they could agree on shifting their time zones, because invariably some countries would get the short stick.
immibis 2y ago
We already have that system, and it's called TAI. You are free to use TAI instead of UTC in your computing projects, and don't have to try to change the definition of UTC.
- anamexis 2y ago
  > You are free to use TAI instead of UTC in your computing projects, and don't have to try to change the definition of UTC. Not if you want to interoperate with basically any other system that uses time.
  - AnotherGoodName 2y ago
    Which is a very good reason to abolish the leap second in UTC to make it the same as TAI time. We can then make a new standard that includes the leap seconds and add them to that (which computers will only ever deal with when they format datetime). Leap seconds are absolutely part of the local datetime conversion functionality of time and not part of the counting functionality. Unix time should never have been different from TAI time in the first place but somewhere along the line some idiot made the absolute undeniable blunder of putting the seconds offset of the suns position relative to earth in the counter of seconds rather than putting it in function that formats the local datetime. Anyway here we are. It’s totally fair that UTC includes leap seconds but unfortunately they passed on UTC as is into the unixtime seconds counter which makes no sense since computers don’t print UTC datetime directly anyway, they have a special date() formatting functions that could easily and problem free add seconds as needed. So what’s the solution? Well telling everyone to suddenly adopt TAI is difficult. But we could just abolish leap seconds from UTC effectively migrating everyone without them realising it. Now I know that sounds odd. After all this blunder wasn’t done by the UTC creators, it was the Unix guys that fucked up here. UTC is literally meant to track the sun after all. But still it’s the easiest fix and we can always create a new UTC, UTC_leap_seconds, that we can use in our datetime printing functions if we want. Abolishing leap seconds from UTC and thus Unixtime will make the world run more smoothly. It’s also been planned as we speak so you don’t need to do anything but wait! :)
    - 2y ago
OtherShrezzing 2y ago
>So let's just wait until there's 15 minutes of error - a couple of millenia from now. Then move the UTC prime meridian about 3.75 degrees / 400km, fixing the error while keeping UTC monotonically increasing 1 second per second. Shifting the prime meridian 400km seems like it'd have some unintended consequences akin to the Y2K problem. Its physical location is used as a reference point in some coordinate systems, ECEF for example.
- Analemma_ 2y ago
  You don't need to move the prime meridian, you just need countries to update their individual time zone offsets from UTC, which is already a well-supported path that happens all the time. If we abolish leap seconds, countries would just wait until solar noon drifted ~30 minutes (which would take centuries), then just do a TZ offset update. Nothing could be simpler.
  - mywittyname 2y ago
    Are you suggesting a solution akin to UTC-4:00 is now UTC-4:00:01? That sounds like a headache of epic proportions when contrasted with the alternative of a leap seconds.
    - School-Cotton 2y ago
      No, they're suggesting a solution akin to Eastern Kazakhstan was on UTC+6:00:00 one day, and on UTC+5:00:00 the next day. This actually happened last March[0] and I'm not aware of anyone outside Kazakhstan being inconvenienced by it at all. tzdb updates happen several times a year and everything keeps working fine. 0: https://data.iana.org/time-zones/tzdb-2024a/NEWS https://data.iana.org/time-zones/tzdb-2024a/NEWS
    - Analemma_ 2y ago
      No, I'm saying that e.g. Central Europe Time keeps being defined as "UTC+1" for the next few centuries until solar noon has drifted about 30 minutes away from civil noon, then CET's definition changes to be UTC+0 or UTC+0:30. This is a time zone update of the sort which happens constantly (e.g. in 2017, Chile changed its TZ offset, Haiti started using DST and Mongolia stopped using DST. A TZ offset change to account for clock drift would be exactly the same)
eCa 2y ago
> So let's just wait until there's 15 minutes of error - a couple of millenia from now. Then move the UTC prime meridian about 3.75 degrees / 400km Perhaps a couple of millenia down the road, we have the technology to speed up/down the rotation of the Earth in order to keep it synced with UTC.
mlyle 2y ago
> NEEDS sub-second precision To be clear, for decades, we've not sought sub-second precision. We've sought precision of a second. Maybe we should seek more-- the big problem with leap seconds is that they've been rare enough to not be tested completely well, but common enough to provoke problems. > And to update our clocks, use the one mechanism that we already rely on comfortably - timezones. Add 15 minutes to each timezone, the same way we handle DST now. Then everything in the world that displays time is going to need a software update when you're going to do this, or it will show time off by 15 minutes. I do think it could be sane to let UTC's offset to drift up to +3.0 to address this temporary trend of a "fast Earth". Of course, that's going to make leap seconds rare for awhile, and it will come back and bite us when the recently-untested event of a positive leap second happens again.
- eqvinox 2y ago
  > Then everything in the world that displays time is going to need a software update Have you seen how often tzdata updates are published? There tend to be multiple each year. Stuff already should be auto updating this. (Python, but good reference: https://github.com/python/tzdata/releases https://github.com/python/tzdata/releases )
  - mlyle 2y ago
    Yes, stuff should be, but a 15 minute adjustment within a zone suddenly is going to screw a lot of devices. Not everything that consumes UTC is internet-connected. Heck, every existing radio-derived clock that presents time to users would be obsolete (lots of GPS, WWV/DCF watches, etc). A lot of them have TZ-related breakage, but they usually let you set a manual hour offset or consume a daylight flag.
    - School-Cotton 2y ago
      I think you are underestimating how long the scales are here. It could take 1000 years to be off by 15 minutes. By this time every electronic device that exists today will be either gone or in a museum.
layer8 2y ago
> So let's just wait until there's 15 minutes of error - a couple of millenia from now. This might already happen in 200-300 years, because the delta increases quadratically: https://www.ucolick.org/~sla/leapsecs/deltat.html https://www.ucolick.org/~sla/leapsecs/deltat.html
billpg 2y ago
"move the UTC prime meridian" We'd have two prime meridians. One for time and another for longitude. (Not a deal breaker but we'd have to plan for it.)
- slavik81 2y ago
  We have many prime meridians for longitude. The location of 0° on Earth is not the same in every datum. We also moved the traditional prime meridian by a hundred meters back in 1974 with the adoption of the IERS Reference Meridian.
  - paulddraper 2y ago
    Said another way, the prime meridian adjusted by (at max deviation) 0.1km 50 years ago and hasn't been changed since.* *Though on a small scale, tectonic movements fuzz the idea of "location" in general.
jandrese 2y ago
I wouldn't even suggest a solution. Let the people thousands of years in the future figure it out. Working out solutions now is like asking people from the time of Jesus what we should do about the clock for a worldwide computerized network.
tim333 2y ago
I vote to correct the clocks once a century. Then it'd be infrequent enough to have a big celebration rather than being annoying.
jimbobthrowawy 2y ago
> Every system can handle a leap-hour, they happen twice a year in many countries, courtesy of DST. Any DST aware system I've checked handles this as a timezone change rather than changing the underlying time, expressed in UTC. Even for locations where DST's onset removes an hour rather than adding one.

throw0101b 2y ago

> That doesn't feel like something that NEEDS sub-second precision. It does not need to be sub-second, but sub-seconds add up over time. The Julian calendar wasn't that far off, but it was cumulative, so to fix things it took a ten day jump: * https://en.wikipedia.org/wiki/Gregorian_calendar https://en.wikipedia.org/wiki/Gregorian_calendar It is considered easier to have a few small(er) semi-regular jumps than suddenly having to making giant, sudden, one-off jump in the future.

skrebbel 2y ago
We make small semi-regular changes to timezones all the time. DST switches, governments arbitrarily deciding that their country is going yo be in a different timezone (at a 2 day notice), or move the DST switch day by 2 weeks, etc etc. This is a solved problem and it happens all the time. The systems and datastructures that can deal with this (eg tzdata and the process & people behind it) are already in place.
- throw0101c 2y ago
  > This is a solved problem and it happens all the time. UTC changing does not happen all the time: what the 'all the time' thing is a display/UI offeset against UTC. Time itself is not changed in those situations, but would be with a 'UTC jump'. The closest thing we get to universal time 'changing' are leap years and February 29, and we regularly get stories about people messing that up. And if something as common and regular as that gets fumbled I have little hope for pulling off a one-off jump of UTC. It is coördinating the universal part that I would imagine to be the difficult part.
  - skrebbel 2y ago
    Then just keep UTC when it is? (ie allow its prime meridian to shift away from Greenwich) Adjust all the timezones by half an hour in a few millennia. It’s really both fine and up to our grand-grand-grand-grand-etc-children to decide. Really, this is a non-problem.
    - organsnyder 2y ago
      > It’s really both fine and up to our grand-grand-grand-grand-etc-children to decide. I'd rather build gradual adjustments into our systems so that they have to be resilient to this sort of thing. Sure, leaving it up to our distant descendants is enticing, but then they're going to have a Y2K-sized problem to fix. I'd rather leave a legacy of systems that were designed to be resilient.
      - School-Cotton 2y ago
        > then they're going to have a Y2K-sized problem to fix. No they aren't. tzdb updates happen several times a year already, and you don't notice.
        organsnyder 2y ago
        The suggestion I was responding to was to basically stop doing this.
School-Cotton 2y ago
It feels like you missed the main point. Time-zone changes are already very easy to handle and are sufficient for dealing with this problem without having to use a leap second or leap minute ever.
- throw0101c 2y ago
  > Time-zone changes are already very easy to handle and are sufficient for dealing with this problem without having to use a leap second or leap minute ever. TZ changes are a display delta against UTC. The closest thing we get to universal time 'changing' are leap years and February 29, and we regularly get stories about people messing that up. If something as common as February 29 is fumbled, what are the odds of pulling a one-off event? And as someone who was a sysadmin when the US changed its TZ rules many moons ago, the sudden rule change was anything but straight-forward given the fairly static nature that they had been for the long history of software development that had occurred until that point: a lot of software is US-developed, and there was little/zero consideration to updating rules. (Though I think that event caused a lot of developers to be more understanding.)
  - afiori 2y ago
    In 400 years we can define new 30 minutes shifted timezones and in 400 - 500 years governments can slowly change their official timezones (maybe at summer/winter time they shift 30 minutes instead of 60). It does not feel like a big issue.
  - School-Cotton 2y ago
    The point is we don't need to change universal time. Thousands of years from now, when solar time drifts away from UTC enough for a particular country to care, that country can change its time zone. There doesn't need to be any global coordination and the process will be gradual enough that nobody will notice.
    - layer8 2y ago
      The EU already fails to agree on dropping DST (and adjusting time zones in the process), because member states will be affected differently, and neighboring countries that should really be in different time zones benefit from being in the same zone. I doubt they could agree on shifting their time zones, because invariably some countries would get the short stick.

immibis 2y ago

We already have that system, and it's called TAI. You are free to use TAI instead of UTC in your computing projects, and don't have to try to change the definition of UTC.

anamexis 2y ago
> You are free to use TAI instead of UTC in your computing projects, and don't have to try to change the definition of UTC. Not if you want to interoperate with basically any other system that uses time.
- AnotherGoodName 2y ago
  Which is a very good reason to abolish the leap second in UTC to make it the same as TAI time. We can then make a new standard that includes the leap seconds and add them to that (which computers will only ever deal with when they format datetime). Leap seconds are absolutely part of the local datetime conversion functionality of time and not part of the counting functionality. Unix time should never have been different from TAI time in the first place but somewhere along the line some idiot made the absolute undeniable blunder of putting the seconds offset of the suns position relative to earth in the counter of seconds rather than putting it in function that formats the local datetime. Anyway here we are. It’s totally fair that UTC includes leap seconds but unfortunately they passed on UTC as is into the unixtime seconds counter which makes no sense since computers don’t print UTC datetime directly anyway, they have a special date() formatting functions that could easily and problem free add seconds as needed. So what’s the solution? Well telling everyone to suddenly adopt TAI is difficult. But we could just abolish leap seconds from UTC effectively migrating everyone without them realising it. Now I know that sounds odd. After all this blunder wasn’t done by the UTC creators, it was the Unix guys that fucked up here. UTC is literally meant to track the sun after all. But still it’s the easiest fix and we can always create a new UTC, UTC_leap_seconds, that we can use in our datetime printing functions if we want. Abolishing leap seconds from UTC and thus Unixtime will make the world run more smoothly. It’s also been planned as we speak so you don’t need to do anything but wait! :)
  - 2y ago

OtherShrezzing 2y ago

>So let's just wait until there's 15 minutes of error - a couple of millenia from now. Then move the UTC prime meridian about 3.75 degrees / 400km, fixing the error while keeping UTC monotonically increasing 1 second per second. Shifting the prime meridian 400km seems like it'd have some unintended consequences akin to the Y2K problem. Its physical location is used as a reference point in some coordinate systems, ECEF for example.

Analemma_ 2y ago
You don't need to move the prime meridian, you just need countries to update their individual time zone offsets from UTC, which is already a well-supported path that happens all the time. If we abolish leap seconds, countries would just wait until solar noon drifted ~30 minutes (which would take centuries), then just do a TZ offset update. Nothing could be simpler.
- mywittyname 2y ago
  Are you suggesting a solution akin to UTC-4:00 is now UTC-4:00:01? That sounds like a headache of epic proportions when contrasted with the alternative of a leap seconds.
  - School-Cotton 2y ago
    No, they're suggesting a solution akin to Eastern Kazakhstan was on UTC+6:00:00 one day, and on UTC+5:00:00 the next day. This actually happened last March[0] and I'm not aware of anyone outside Kazakhstan being inconvenienced by it at all. tzdb updates happen several times a year and everything keeps working fine. 0: https://data.iana.org/time-zones/tzdb-2024a/NEWS https://data.iana.org/time-zones/tzdb-2024a/NEWS
  - Analemma_ 2y ago
    No, I'm saying that e.g. Central Europe Time keeps being defined as "UTC+1" for the next few centuries until solar noon has drifted about 30 minutes away from civil noon, then CET's definition changes to be UTC+0 or UTC+0:30. This is a time zone update of the sort which happens constantly (e.g. in 2017, Chile changed its TZ offset, Haiti started using DST and Mongolia stopped using DST. A TZ offset change to account for clock drift would be exactly the same)

eCa 2y ago

> So let's just wait until there's 15 minutes of error - a couple of millenia from now. Then move the UTC prime meridian about 3.75 degrees / 400km Perhaps a couple of millenia down the road, we have the technology to speed up/down the rotation of the Earth in order to keep it synced with UTC.

mlyle 2y ago

> NEEDS sub-second precision To be clear, for decades, we've not sought sub-second precision. We've sought precision of a second. Maybe we should seek more-- the big problem with leap seconds is that they've been rare enough to not be tested completely well, but common enough to provoke problems. > And to update our clocks, use the one mechanism that we already rely on comfortably - timezones. Add 15 minutes to each timezone, the same way we handle DST now. Then everything in the world that displays time is going to need a software update when you're going to do this, or it will show time off by 15 minutes. I do think it could be sane to let UTC's offset to drift up to +3.0 to address this temporary trend of a "fast Earth". Of course, that's going to make leap seconds rare for awhile, and it will come back and bite us when the recently-untested event of a positive leap second happens again.

eqvinox 2y ago
> Then everything in the world that displays time is going to need a software update Have you seen how often tzdata updates are published? There tend to be multiple each year. Stuff already should be auto updating this. (Python, but good reference: https://github.com/python/tzdata/releases https://github.com/python/tzdata/releases )
- mlyle 2y ago
  Yes, stuff should be, but a 15 minute adjustment within a zone suddenly is going to screw a lot of devices. Not everything that consumes UTC is internet-connected. Heck, every existing radio-derived clock that presents time to users would be obsolete (lots of GPS, WWV/DCF watches, etc). A lot of them have TZ-related breakage, but they usually let you set a manual hour offset or consume a daylight flag.
  - School-Cotton 2y ago
    I think you are underestimating how long the scales are here. It could take 1000 years to be off by 15 minutes. By this time every electronic device that exists today will be either gone or in a museum.

layer8 2y ago

> So let's just wait until there's 15 minutes of error - a couple of millenia from now. This might already happen in 200-300 years, because the delta increases quadratically: https://www.ucolick.org/~sla/leapsecs/deltat.html https://www.ucolick.org/~sla/leapsecs/deltat.html

billpg 2y ago

"move the UTC prime meridian" We'd have two prime meridians. One for time and another for longitude. (Not a deal breaker but we'd have to plan for it.)

slavik81 2y ago
We have many prime meridians for longitude. The location of 0° on Earth is not the same in every datum. We also moved the traditional prime meridian by a hundred meters back in 1974 with the adoption of the IERS Reference Meridian.
- paulddraper 2y ago
  Said another way, the prime meridian adjusted by (at max deviation) 0.1km 50 years ago and hasn't been changed since.* *Though on a small scale, tectonic movements fuzz the idea of "location" in general.

jandrese 2y ago

I wouldn't even suggest a solution. Let the people thousands of years in the future figure it out. Working out solutions now is like asking people from the time of Jesus what we should do about the clock for a worldwide computerized network.

tim333 2y ago

I vote to correct the clocks once a century. Then it'd be infrequent enough to have a big celebration rather than being annoying.

jimbobthrowawy 2y ago

> Every system can handle a leap-hour, they happen twice a year in many countries, courtesy of DST. Any DST aware system I've checked handles this as a timezone change rather than changing the underlying time, expressed in UTC. Even for locations where DST's onset removes an hour rather than adding one.