4 ms·

Your proposal is to make the time Standard of billions of people not match what they experience, on behalf of a few space probes, none of which will use it.

by ncmncm 4y ago

XorNot 4y ago
Meta don't want leap seconds because leap seconds make distributed system cluster synchronization tricky, because that's the only case where an extra second here or there actually matters. Across all the devices in my house that have a clock in them, the time drift is a little over an hour and it doesn't make the slightest bit of difference to me: internet connected computers being the most accurate. Between individual computers, thanks to filesystem semantics, drifts of up to 2 seconds are expected and generally considered "identical" - it certainly doesn't matter for file sync applications. So either we want to build a time standard that can be transformed in a sensible way to all the others which are useful - in which case something which works for interstellar timekeeping would be a sensible step, given that relativistic issues crop up even in Earth orbit, or we're building a time system "for humans" in which case everything we have now is fine, and will by definition be messy because time and timezones change all the time.
- nullc 4y ago
  That is absolutely not the only case where an extra second here or there matters. It's just for distributed systems the OTHER ways of dealing with the problems leapseconds create (e.g. using a local monotone clock) aren't available. But even where they are available leapseconds still create issues because they're extremely difficult to test and are often handled somewhat incorrectly. UTC without leapseconds would in no way be less "for humans". After 4000 years of drift the effect on the solar noon would be about the same as you get driving to the next state over.
  - XorNot 4y ago
    Except as I noted up thread we've already got "UTC without leap seconds" - it's UNIX epoch time which is defined to ignore leap seconds. Leap seconds are still seconds so even with GPS sync, if all you're doing is tracking 1000ms increments then we have a format already which doesn't have them.
    - ncmncm 4y ago
      Except everybody is already using UTC, and will not change from UTC to "Unix epoch time" on your say-so. Or to TAI or any other crack-brained system you can think of from your armchair, including all the hardware that cannot be changed without throwing it away and buying new. All we need to do is simply choose not to announce that all the software in the world that (might have) "got leap seconds wrong" but still has to talk to the other half that (might have) "got leap seconds wrong" will be officially broken, this year. Or next year. Etc.
    - nullc 4y ago
      Unless I am misunderstanding what you are writing, you're mistaken about unix time, in practice. In unix time there are 86400 "seconds" per day since the epoch. On days when there is a leapsecond the timestamp of the leapsecond is given out for two (TAI) seconds. A result is that unix time stays in sync with UTC and the difference between them doesn't change. The belief that conventional unix time is somehow leapsecond free is a common source of leapsecond handling bugs. :( It results from misleading standards text which states that it doesn't have leapseconds, which it technically doesn't-- instead leaves the second undefined, which implementations distort to make unix time match UTC. If your goal is to measure accurate durations, synchronize distributed systems, or point telescopes-- unix time will not solve any of your leap second issues.
      - XorNot 4y ago
        Thanks for the clarification, but I think my underlying point still stands: ignore leap seconds - invent a time standard without them, which in practice would probably be Unix-time-sans-leap-things, and calibrate off against that. It's plain weird to rewrite the world which doesn't actually care about leap seconds for use-cases which don't work in normal human reaction or processing times. 1000ms is a value only relevant to high precision applications, which are perfectly fine not being tied to a precise date or solar rotation or anything. This feels like a programmers without science training issue: all models are models and you choose the one useful for your purpose. It's particularly galling coming from Meta who are large enough to just do this, write the code, and submit a standard for consideration by the tech-industry.

Your proposal is to make the time Standard of billions of people not match what they experience, on behalf of a few space probes, none of which will use it.

by ncmncm 4y ago

Your proposal is to make the time Standard of billions of people not match what they experience, on behalf of a few space probes, none of which will use it.

XorNot 4y ago

Meta don't want leap seconds because leap seconds make distributed system cluster synchronization tricky, because that's the only case where an extra second here or there actually matters. Across all the devices in my house that have a clock in them, the time drift is a little over an hour and it doesn't make the slightest bit of difference to me: internet connected computers being the most accurate. Between individual computers, thanks to filesystem semantics, drifts of up to 2 seconds are expected and generally considered "identical" - it certainly doesn't matter for file sync applications. So either we want to build a time standard that can be transformed in a sensible way to all the others which are useful - in which case something which works for interstellar timekeeping would be a sensible step, given that relativistic issues crop up even in Earth orbit, or we're building a time system "for humans" in which case everything we have now is fine, and will by definition be messy because time and timezones change all the time.

nullc 4y ago
That is absolutely not the only case where an extra second here or there matters. It's just for distributed systems the OTHER ways of dealing with the problems leapseconds create (e.g. using a local monotone clock) aren't available. But even where they are available leapseconds still create issues because they're extremely difficult to test and are often handled somewhat incorrectly. UTC without leapseconds would in no way be less "for humans". After 4000 years of drift the effect on the solar noon would be about the same as you get driving to the next state over.
- XorNot 4y ago
  Except as I noted up thread we've already got "UTC without leap seconds" - it's UNIX epoch time which is defined to ignore leap seconds. Leap seconds are still seconds so even with GPS sync, if all you're doing is tracking 1000ms increments then we have a format already which doesn't have them.
  - ncmncm 4y ago
    Except everybody is already using UTC, and will not change from UTC to "Unix epoch time" on your say-so. Or to TAI or any other crack-brained system you can think of from your armchair, including all the hardware that cannot be changed without throwing it away and buying new. All we need to do is simply choose not to announce that all the software in the world that (might have) "got leap seconds wrong" but still has to talk to the other half that (might have) "got leap seconds wrong" will be officially broken, this year. Or next year. Etc.
  - nullc 4y ago
    Unless I am misunderstanding what you are writing, you're mistaken about unix time, in practice. In unix time there are 86400 "seconds" per day since the epoch. On days when there is a leapsecond the timestamp of the leapsecond is given out for two (TAI) seconds. A result is that unix time stays in sync with UTC and the difference between them doesn't change. The belief that conventional unix time is somehow leapsecond free is a common source of leapsecond handling bugs. :( It results from misleading standards text which states that it doesn't have leapseconds, which it technically doesn't-- instead leaves the second undefined, which implementations distort to make unix time match UTC. If your goal is to measure accurate durations, synchronize distributed systems, or point telescopes-- unix time will not solve any of your leap second issues.
    - XorNot 4y ago
      Thanks for the clarification, but I think my underlying point still stands: ignore leap seconds - invent a time standard without them, which in practice would probably be Unix-time-sans-leap-things, and calibrate off against that. It's plain weird to rewrite the world which doesn't actually care about leap seconds for use-cases which don't work in normal human reaction or processing times. 1000ms is a value only relevant to high precision applications, which are perfectly fine not being tied to a precise date or solar rotation or anything. This feels like a programmers without science training issue: all models are models and you choose the one useful for your purpose. It's particularly galling coming from Meta who are large enough to just do this, write the code, and submit a standard for consideration by the tech-industry.