4 ms·

Before people freak out, most time systems that already support leap seconds should also be able to support negative leap seconds. You can just smear a second b

by dexwiz 3y ago

Before people freak out, most time systems that already support leap seconds should also be able to support negative leap seconds. You can just smear a second by speeding up a clocks temporarily. And it will counteract the drift between UTC and TAI. https://developers.google.com/time/smear#:~:text=During%20the%20smear%2C%20clocks%20run,under%200.5%20s%20behind%20UTC https://developers.google.com/time/smear#:~:text=During%20th....

pclmulqdq 3y ago
Google likes smearing (they famously published a white paper on it), but not everyone does it since it causes error in your measurements of duration. The most common alternative is having a minute that runs to either :58 or :60 while keeping the size of a second the same.
- mrngm 3y ago
  I'm not sure where to find the white paper, but this blog post [2011] probably has most details as well. Its key take-aways: - their (and probably others') distributed systems expect time to move forwards (synchronization, "happens after", etc) - repetition of one second is difficult to accommodate for, e.g. with disk writes or storage of e-mail messages - the initial leap smear was a hack/patch in their NTP servers by not setting LI (leap indicator), but modulating time within a window w before midnight: lie(t) = (1.0 - cos(pi * t / w)) / 2.0 - they tested both positive and negative leap smear on a set of 10k servers - leap smears eliminate the need for programmers to handle leap seconds [2011]: https://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html https://googleblog.blogspot.com/2011/09/time-technology-and-... (edit: list markup)
  - throw0101c 3y ago
    > - their (and probably others') distributed systems expect time to move forwards (synchronization, "happens after", etc) Time moves forward with both positive and negative leap seconds. With the positive ones, which we've seen before, we go from 23:59:59 to 23:59:60 to 00:00:00. Always forward. With negative ones, which have not been seen in the wild, it goes from 23:59:58 to 00:00:00, skipping :59. Also always forward.
    - toast0 3y ago
      Well, the problem is most systems are on unixtime, and unixtime doesn't allow for a :60. Traditionally, :59 is repeated, so the integer seconds is still monotonic, but the fractional part repeats. This confuses many applications. And ocassionaly confuses the Linux kernel, too [1]. Other kernels may have done better. I think a negative leap second is less likely to cause the same sorts of problems. Otoh, it's never happened before, and leap seconds are generally not well tested. [1] https://www.networkworld.com/article/711440/software-linux-is-culprit-in-leap-second-lapses-cassandra-exec.html https://www.networkworld.com/article/711440/software-linux-i...
      - account42 3y ago
        Including leap seconds in unix time was a mistake - it should follow TAI instead of UTC and leave leap seconds entirely as a matter of the formatting/timezone code.
    - mrngm 3y ago
      From the blog post: > Very large-scale distributed systems, like ours, demand that time be well-synchronized and expect that time always moves forwards. Computers traditionally accommodate leap seconds by setting their clock backwards by one second at the very end of the day. Not quite "always forward".
bxparks 3y ago
In theory, yes. But in practice... I wouldn't be surprised to see many systems fail. It's probably not a code path that's been tested much, if at all. Kinda like those systems that went down on Feb 29, 2024. I mean, how does an app in the 21st century not handle leap day? Yet it happened.
- diggan 3y ago
  > I mean, how does an app in the 21st century not handle leap day? We'll always have programmers that have less than 4 years experience programming and hadn't even considered leap days when programming "This should happen every last day of the month" or whatever. One would think libraries would catch this one way or another, but some people are hellbent at doing things their own way and then... Well.
  - ryandrake 3y ago
    > We'll always have programmers that have less than 4 years experience programming and hadn't even considered leap days Or, you know they considered it because they left a comment in their code like // TODO: Handle leap year LOL Just as bad. Don’t roll your own time handling code.
deleted 3y ago
[deleted]
zarzavat 3y ago
I don’t buy that. While positive leap seconds can be mitigated at the OS level, negative leap seconds need to be supported at the application level. A positive leap second gives you a discontinuous function from UTC to TAI. But a negative leap second means a function can’t exist at all, because the same timestamp in UTC now corresponds to two moments in time. If someone gives you a timestamp in UTC you can’t know which second it refers to - you would have to switch to giving timestamps in TAI.
- binarycoffee 3y ago
  While this doesn't change the essence of your claim, the problem is not with UTC timestamps but with Unix timestamps. UTC timestamps (HH:MM:SS) are actually unique because the extra second inserted is assigned the numeral 60. Unix timestamps do, however, repeat when a leap second is inserted.
  - saltcured 3y ago
    And isn't this problem then the opposite of what is described in the prior post? A timestamp "repeats" to add a second (positive leap second). The subsequent timestamp sequence is delayed relative to its prior offset to TIA. The Google "smear" method works here to slow down the clock rather than repeat values. To drop a second (negative leap second) we have a one second gap in the timestamp sequence. The subsequent timestamp sequence is advanced relative to its prior offset to TIA. This just requires a monotonic jump, as if the computer froze and did not perform any work for one second before resuming with the right clock values.
    - binarycoffee 3y ago
      Oh yes, absolutely, GP got it backward and I went along with it...
throw0101c 3y ago
> You can just smear a second by speeding up a clocks temporarily. And it will counteract the drift between UTC and TAI. No, you cannot "just" do this in many instances. Some folks (especially in regulated industries) need to have a close link to UTC, and so purposefully smearing things would be non-compliant.
- nine_k 3y ago
  Can you provide an example? From my experience, stuff that needs serious synchronization does not care much about absolute time, and optimizes for very low relative offsets. Other stuff is OK with half-second or so in offset, and can tolerate much more.
  - gpderetta 3y ago
    MIFID II requires [1] at most 100us divergence from UTC for timestamps for reportable events. [1] https://ec.europa.eu/finance/securities/docs/isd/mifid/rts/160607-rts-25-annex_en.pdf https://ec.europa.eu/finance/securities/docs/isd/mifid/rts/1...
    - ggm 3y ago
      Which begs the question, was the Google smear inside that limit? Answer; During the smear, clocks run slightly slower than usual. Each second of time in the smeared timescale is about 11.6 μs longer than an SI second as realized in Terrestrial Time.
      - toast0 3y ago
        By design, the Google smear peaks at about 500ms off When :60 starts, Google smear is at 59.500, and when :0 starts, it's at :0.500. IIRC, there were some different strategies on how to modulate the length of the seconds. One method was to make all seconds in the 24 hours around the change uniformly longer; another was to increase second length slowly and then decrease slowly after the leap second. Either way, you'd need to do some math to determine when you were out of compliance, and if that overlapped with time you were operating where compliance was needed. IMHO, better to not smear, and just not trade for a couple seconds around the leap second.
01HNNWZ0MV43FF 3y ago
Or, hear me out, we ditch UTC and only use TAI. Vote for me and I will also: - Get rid of DST - Put the whole USA on EST - Take over the rest of the Americas and do the same for them (New York is basically centrally located as far as meridians go)
- im3w1l 3y ago
  Yes I agree, ideally we should move to using TAI for timestamps, and then leapseconds can be added as part of the timezone calculation when formatting the date for the user.
- kibwen 3y ago
  > Put the whole USA on EST Smearing a single timezone over a four-hour-wide country works for China because the mean Chinese longitudial center of population is inline with Hong Kong/Shenzen/Wuhan; it's safe to say that almost all Chinese people live in the east. Comparatively, the US mean center of population is in Missouri. People in the far west of China already make use of unofficial local timezones precisely because the official timezone isn't designed to serve them; now imagine that behavior but applied to Los Angeles, the second-largest city in the country. At best, you could split the US into two timezones that were two hours apart, with the cutover somewhere around the Colorado/Kansas border. But for optimal results you'd want to pull an India and make each timezone a half-hour offset from UTC, and at that point it's just too much bother.

by dexwiz 3y ago

pclmulqdq 3y ago

Google likes smearing (they famously published a white paper on it), but not everyone does it since it causes error in your measurements of duration. The most common alternative is having a minute that runs to either :58 or :60 while keeping the size of a second the same.

mrngm 3y ago
I'm not sure where to find the white paper, but this blog post [2011] probably has most details as well. Its key take-aways: - their (and probably others') distributed systems expect time to move forwards (synchronization, "happens after", etc) - repetition of one second is difficult to accommodate for, e.g. with disk writes or storage of e-mail messages - the initial leap smear was a hack/patch in their NTP servers by not setting LI (leap indicator), but modulating time within a window w before midnight: lie(t) = (1.0 - cos(pi * t / w)) / 2.0 - they tested both positive and negative leap smear on a set of 10k servers - leap smears eliminate the need for programmers to handle leap seconds [2011]: https://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html https://googleblog.blogspot.com/2011/09/time-technology-and-... (edit: list markup)
- throw0101c 3y ago
  > - their (and probably others') distributed systems expect time to move forwards (synchronization, "happens after", etc) Time moves forward with both positive and negative leap seconds. With the positive ones, which we've seen before, we go from 23:59:59 to 23:59:60 to 00:00:00. Always forward. With negative ones, which have not been seen in the wild, it goes from 23:59:58 to 00:00:00, skipping :59. Also always forward.
  - toast0 3y ago
    Well, the problem is most systems are on unixtime, and unixtime doesn't allow for a :60. Traditionally, :59 is repeated, so the integer seconds is still monotonic, but the fractional part repeats. This confuses many applications. And ocassionaly confuses the Linux kernel, too [1]. Other kernels may have done better. I think a negative leap second is less likely to cause the same sorts of problems. Otoh, it's never happened before, and leap seconds are generally not well tested. [1] https://www.networkworld.com/article/711440/software-linux-is-culprit-in-leap-second-lapses-cassandra-exec.html https://www.networkworld.com/article/711440/software-linux-i...
    - account42 3y ago
      Including leap seconds in unix time was a mistake - it should follow TAI instead of UTC and leave leap seconds entirely as a matter of the formatting/timezone code.
  - mrngm 3y ago
    From the blog post: > Very large-scale distributed systems, like ours, demand that time be well-synchronized and expect that time always moves forwards. Computers traditionally accommodate leap seconds by setting their clock backwards by one second at the very end of the day. Not quite "always forward".

bxparks 3y ago

In theory, yes. But in practice... I wouldn't be surprised to see many systems fail. It's probably not a code path that's been tested much, if at all. Kinda like those systems that went down on Feb 29, 2024. I mean, how does an app in the 21st century not handle leap day? Yet it happened.

diggan 3y ago
> I mean, how does an app in the 21st century not handle leap day? We'll always have programmers that have less than 4 years experience programming and hadn't even considered leap days when programming "This should happen every last day of the month" or whatever. One would think libraries would catch this one way or another, but some people are hellbent at doing things their own way and then... Well.
- ryandrake 3y ago
  > We'll always have programmers that have less than 4 years experience programming and hadn't even considered leap days Or, you know they considered it because they left a comment in their code like // TODO: Handle leap year LOL Just as bad. Don’t roll your own time handling code.

deleted 3y ago

[deleted]

zarzavat 3y ago

I don’t buy that. While positive leap seconds can be mitigated at the OS level, negative leap seconds need to be supported at the application level. A positive leap second gives you a discontinuous function from UTC to TAI. But a negative leap second means a function can’t exist at all, because the same timestamp in UTC now corresponds to two moments in time. If someone gives you a timestamp in UTC you can’t know which second it refers to - you would have to switch to giving timestamps in TAI.

binarycoffee 3y ago
While this doesn't change the essence of your claim, the problem is not with UTC timestamps but with Unix timestamps. UTC timestamps (HH:MM:SS) are actually unique because the extra second inserted is assigned the numeral 60. Unix timestamps do, however, repeat when a leap second is inserted.
- saltcured 3y ago
  And isn't this problem then the opposite of what is described in the prior post? A timestamp "repeats" to add a second (positive leap second). The subsequent timestamp sequence is delayed relative to its prior offset to TIA. The Google "smear" method works here to slow down the clock rather than repeat values. To drop a second (negative leap second) we have a one second gap in the timestamp sequence. The subsequent timestamp sequence is advanced relative to its prior offset to TIA. This just requires a monotonic jump, as if the computer froze and did not perform any work for one second before resuming with the right clock values.
  - binarycoffee 3y ago
    Oh yes, absolutely, GP got it backward and I went along with it...

throw0101c 3y ago

> You can just smear a second by speeding up a clocks temporarily. And it will counteract the drift between UTC and TAI. No, you cannot "just" do this in many instances. Some folks (especially in regulated industries) need to have a close link to UTC, and so purposefully smearing things would be non-compliant.

nine_k 3y ago
Can you provide an example? From my experience, stuff that needs serious synchronization does not care much about absolute time, and optimizes for very low relative offsets. Other stuff is OK with half-second or so in offset, and can tolerate much more.
- gpderetta 3y ago
  MIFID II requires [1] at most 100us divergence from UTC for timestamps for reportable events. [1] https://ec.europa.eu/finance/securities/docs/isd/mifid/rts/160607-rts-25-annex_en.pdf https://ec.europa.eu/finance/securities/docs/isd/mifid/rts/1...
  - ggm 3y ago
    Which begs the question, was the Google smear inside that limit? Answer; During the smear, clocks run slightly slower than usual. Each second of time in the smeared timescale is about 11.6 μs longer than an SI second as realized in Terrestrial Time.
    - toast0 3y ago
      By design, the Google smear peaks at about 500ms off When :60 starts, Google smear is at 59.500, and when :0 starts, it's at :0.500. IIRC, there were some different strategies on how to modulate the length of the seconds. One method was to make all seconds in the 24 hours around the change uniformly longer; another was to increase second length slowly and then decrease slowly after the leap second. Either way, you'd need to do some math to determine when you were out of compliance, and if that overlapped with time you were operating where compliance was needed. IMHO, better to not smear, and just not trade for a couple seconds around the leap second.

01HNNWZ0MV43FF 3y ago

Or, hear me out, we ditch UTC and only use TAI. Vote for me and I will also: - Get rid of DST - Put the whole USA on EST - Take over the rest of the Americas and do the same for them (New York is basically centrally located as far as meridians go)

im3w1l 3y ago
Yes I agree, ideally we should move to using TAI for timestamps, and then leapseconds can be added as part of the timezone calculation when formatting the date for the user.
kibwen 3y ago
> Put the whole USA on EST Smearing a single timezone over a four-hour-wide country works for China because the mean Chinese longitudial center of population is inline with Hong Kong/Shenzen/Wuhan; it's safe to say that almost all Chinese people live in the east. Comparatively, the US mean center of population is in Missouri. People in the far west of China already make use of unofficial local timezones precisely because the official timezone isn't designed to serve them; now imagine that behavior but applied to Los Angeles, the second-largest city in the country. At best, you could split the US into two timezones that were two hours apart, with the cutover somewhere around the Colorado/Kansas border. But for optimal results you'd want to pull an India and make each timezone a half-hour offset from UTC, and at that point it's just too much bother.