3 ms·

Does anyone have an actual example where leap seconds are a problem? Specifically one that can't be solved simply by using Atomic Time? Maybe then we can figur

Does anyone have an actual example where leap seconds are a problem? Specifically one that can't be solved simply by using Atomic Time? Maybe then we can figure out what the problem we're trying to solve is. Few people or systems even interact with a clock that is precise enough to detect the difference, and instead rely on clocks that are 100's or even 1000's of times less accurate than what would be required to even detect a leap second. And these clocks undergo thousands of corrections between leap seconds without a complaint. We add an entire day to the calendar about every 4 years. It's not a problem because everyone is aware of it. So I think the only real thing that needs to change about leap seconds is awareness of them. Leap seconds are needed in civil time because people's schedules are still dominated by the Sun. Not to the second, maybe not even to the hour. But the leap second was chosen because it's large enough to be infrequent, and tiny enough that only a tiny fraction of systems will notice.

AnotherGoodName 2y ago
Yes if you use atomic time you won’t encounter these issues. Unixtime made a blunder of incorporating the leap seconds all those years ago so it’s not atomic hence the issue. Now you might think it’s crazy that Unix time incorporated non-atomic leap seconds when it doesn’t incorporate any other part of the local sun relative position in its counter and you’d be 100% right in that. Leap seconds absolutely belong in the local time printing functions and nowhere else. But the blunder was made and now computers by default don’t have atomic time and here we are.
SonicScrub 2y ago
Leap seconds are a problem because I have to deal with existing systems that use leap seconds and those that do not. Getting those systems in sync can be pain sometimes because of conversion from one format to another. Is it insurmountable? No. Is it annoying? Yes. Does it occasionally cause bugs that waste time and resources? Absolutely. I'd love to snap my fingers and make everyone use TAI, but unfortunately I'm stuck with UTC, GPS and TAI depending on sources.
- gmiller123456 2y ago
  Why are you trying to sync systems that use leap seconds and ones that don't? It sounds like you've invented your own time system.
  - SonicScrub 2y ago
    Time aligning GPS data with other sensors/systems that record in UTC. I'm combining data from multiple different sources together that I do not control. The duration of the data is long enough that an occasional leap second slips in and offsets things.
    - gmiller123456 2y ago
      So, you just need to set up a scheduled task to download the leap seconds file from the IERS once every six months?
      - SonicScrub 2y ago
        The codebase does pretty much exactly that, yes. Still causes the occasional hiccup though when new data is inevitably not labelled appropriately. Not exactly the kind of thing that causes catastrophic failure. More so the kind of thing that periodically pops up to be annoying.
        gmiller123456 2y ago
        Ok, so it's not "keeping them in sync" as you stated in your first post, it's not a "leap second sneaking in" as in your second post. Now it is somehow data that is not labeled, and only becomes a problem during leap seconds. I'm sure you can see how changing your story and lack of details would make someone skeptical that the problem even exists. If there really is a problem I'm really interested in hearing what it is. But it doesn't sound like you plan to be straight forward about explaining it.
nitwit005 2y ago
> Leap seconds are needed in civil time because people's schedules are still dominated by the Sun. Not to the second, maybe not even to the hour. Sometimes multiple hours off. China has a single time zone. As far as I can tell, people care very little about the clocks being in sync with the sun. We've effectively run massive experiments demonstrating this.
- gmiller123456 2y ago
  What experiments are those? I don't doubt if you lock someone in a room they'll lose sync with the sun, but people in society do rely on it. The fact that we use DST in the face of very vocal opposition shows a lot of people do care about it. The existence of China as an outlier isn't much evidence. The most people on one side do not keep the same schedule as those on the other. If daylight really weren't an issue, there would be only one timezone for the entire Earth. So you can't point to one while ignoring the reason all of the others exist.
aidenn0 2y ago
> Does anyone have an actual example where leap seconds are a problem? Specifically one that can't be solved simply by using Atomic Time? Maybe then we can figure out what the problem we're trying to solve is. Any time that is supposed to represent both a wall-clock time has to deal with it. There is currently no known answer to the question "What is the interval between the unix time stamps @1720026000 and @182002600" However, there is a well defined answer to "What is the UTC time for @182002600" and thus also "what is the local time in a timezone with UTC offset X for @182002600" If we were to redefine Unix time to use Atomic Time, then we could answer the first question but not the second. > We add an entire day to the calendar about every 4 years. It's not a problem because everyone is aware of it. So I think the only real thing that needs to change about leap seconds is awareness of them. It's not just "about every 4 years" it's precisely "every 4 years, except for centuries, except for quad-centuries." If you give me any year, I can tell you if it will be a leap year. I can program a non-internet connected device and it will get leap years right indefinitely. Leap seconds are not predictable, but rather determined empirically and announced about 6 months ahead of time. Any device that wants to properly account for them needs to be updated at least every 6 months to be correct.
- gmiller123456 2y ago
  Specifically when is not knowing UTC will skip a second six months later a problem for you? As I said, you don't know the interval between any two seconds on your clock, a sync or frequency change can happen at any time. And if you really needed to know the interval at those points, Atomic Time can serve your purpose.

AnotherGoodName 2y ago

Yes if you use atomic time you won’t encounter these issues. Unixtime made a blunder of incorporating the leap seconds all those years ago so it’s not atomic hence the issue. Now you might think it’s crazy that Unix time incorporated non-atomic leap seconds when it doesn’t incorporate any other part of the local sun relative position in its counter and you’d be 100% right in that. Leap seconds absolutely belong in the local time printing functions and nowhere else. But the blunder was made and now computers by default don’t have atomic time and here we are.

SonicScrub 2y ago

Leap seconds are a problem because I have to deal with existing systems that use leap seconds and those that do not. Getting those systems in sync can be pain sometimes because of conversion from one format to another. Is it insurmountable? No. Is it annoying? Yes. Does it occasionally cause bugs that waste time and resources? Absolutely. I'd love to snap my fingers and make everyone use TAI, but unfortunately I'm stuck with UTC, GPS and TAI depending on sources.

gmiller123456 2y ago
Why are you trying to sync systems that use leap seconds and ones that don't? It sounds like you've invented your own time system.
- SonicScrub 2y ago
  Time aligning GPS data with other sensors/systems that record in UTC. I'm combining data from multiple different sources together that I do not control. The duration of the data is long enough that an occasional leap second slips in and offsets things.
  - gmiller123456 2y ago
    So, you just need to set up a scheduled task to download the leap seconds file from the IERS once every six months?
    - SonicScrub 2y ago
      The codebase does pretty much exactly that, yes. Still causes the occasional hiccup though when new data is inevitably not labelled appropriately. Not exactly the kind of thing that causes catastrophic failure. More so the kind of thing that periodically pops up to be annoying.
      - gmiller123456 2y ago
        Ok, so it's not "keeping them in sync" as you stated in your first post, it's not a "leap second sneaking in" as in your second post. Now it is somehow data that is not labeled, and only becomes a problem during leap seconds. I'm sure you can see how changing your story and lack of details would make someone skeptical that the problem even exists. If there really is a problem I'm really interested in hearing what it is. But it doesn't sound like you plan to be straight forward about explaining it.

nitwit005 2y ago

> Leap seconds are needed in civil time because people's schedules are still dominated by the Sun. Not to the second, maybe not even to the hour. Sometimes multiple hours off. China has a single time zone. As far as I can tell, people care very little about the clocks being in sync with the sun. We've effectively run massive experiments demonstrating this.

gmiller123456 2y ago
What experiments are those? I don't doubt if you lock someone in a room they'll lose sync with the sun, but people in society do rely on it. The fact that we use DST in the face of very vocal opposition shows a lot of people do care about it. The existence of China as an outlier isn't much evidence. The most people on one side do not keep the same schedule as those on the other. If daylight really weren't an issue, there would be only one timezone for the entire Earth. So you can't point to one while ignoring the reason all of the others exist.

aidenn0 2y ago

> Does anyone have an actual example where leap seconds are a problem? Specifically one that can't be solved simply by using Atomic Time? Maybe then we can figure out what the problem we're trying to solve is. Any time that is supposed to represent both a wall-clock time has to deal with it. There is currently no known answer to the question "What is the interval between the unix time stamps @1720026000 and @182002600" However, there is a well defined answer to "What is the UTC time for @182002600" and thus also "what is the local time in a timezone with UTC offset X for @182002600" If we were to redefine Unix time to use Atomic Time, then we could answer the first question but not the second. > We add an entire day to the calendar about every 4 years. It's not a problem because everyone is aware of it. So I think the only real thing that needs to change about leap seconds is awareness of them. It's not just "about every 4 years" it's precisely "every 4 years, except for centuries, except for quad-centuries." If you give me any year, I can tell you if it will be a leap year. I can program a non-internet connected device and it will get leap years right indefinitely. Leap seconds are not predictable, but rather determined empirically and announced about 6 months ahead of time. Any device that wants to properly account for them needs to be updated at least every 6 months to be correct.

gmiller123456 2y ago
Specifically when is not knowing UTC will skip a second six months later a problem for you? As I said, you don't know the interval between any two seconds on your clock, a sync or frequency change can happen at any time. And if you really needed to know the interval at those points, Atomic Time can serve your purpose.