4 ms·

Mildly disappointed that AWS isn't giving Google credit for coming up with the idea of "time smearing", which they're using here: http://googleblog.blogspot.co

Mildly disappointed that AWS isn't giving Google credit for coming up with the idea of "time smearing", which they're using here: http://googleblog.blogspot.com.au/2011/09/time-technology-and-leaping-seconds.html http://googleblog.blogspot.com.au/2011/09/time-technology-an...

jasonmp85 11y ago
Agreed that they definitely should have given some credit. I was unfamiliar with the concept (and didn't even know the term). The AWS post raised more questions than it answered, but that Google one is excellent and coins a great term.
hillsarealiv3 11y ago
The idea of spreading a leap second over a longer period is not unique to Google e.g. www.quadibloc.com/science/cal06.htm The idea itself is actually rather obvious.
- jpatokal 11y ago
  Most good ideas are obvious in hindsight. ;) But AFAIK, Google was the first to do this live and in production by hacking NTP, which is (apparently?) the same as what Amazon is doing.
  - chronial 11y ago
    SAP Systems have been doing this for many, many years live and in production for DST adjustments. Not sure about leap seconds.
    - RedNifre 11y ago
      What? How does it make sense to spread DST adjustments over a long time?
      - Namrog84 11y ago
        What if in a dst jump. It had. Pay namrog84 $100 at 1:30am. Then 2 rolls around and it's 1am again and now I get paid a second time. Win! But if dst was smeared over a day. This would be easily prevented.
- fanf2 11y ago
  See also Markus Kuhn's description of smoothed leap seconds from 2005: https://www.cl.cam.ac.uk/~mgk25/time/utc-sls/ https://www.cl.cam.ac.uk/~mgk25/time/utc-sls/
- a-priori 11y ago
  The time-smearing technique reminds me of how the Erlang platform (ERTS) adjusts its internal timekeeping to changes in the system's clock. If the system's clock jumps, then Erlang makes its internal clock tick faster or slower than the system's clock by at most 1% in order to resynchronize. http://www.erlang.org/doc/apps/erts/time_correction.html http://www.erlang.org/doc/apps/erts/time_correction.html
acqq 11y ago
It looks to me AWS is using the different algorithm. See my other comment here.
Terretta 11y ago
Google didn't come up with that first. I'm aware of a number companies with multiple data enters (my last co had 14 around the world) and coordinated logs or time sensitive services that used this technique. I personally implemented it 12 years ago, to support (a) a kind of geo-balancing based on time coordinated spoofed DNS responses, and (b) time stamped URL token expiration validation, sensitive to seconds, across distributed datacenters. I got the idea from Microsoft Windows' ability to drift the clock back into sync. Google has adopted or reinvented a lot, and gets credit because they have extra time and resources to publish. // TBC, they also invented a lot. But not this one. Sibling comments point out other implementations predating Google as well.
deleted 11y ago
[deleted]

jasonmp85 11y ago

Agreed that they definitely should have given some credit. I was unfamiliar with the concept (and didn't even know the term). The AWS post raised more questions than it answered, but that Google one is excellent and coins a great term.

hillsarealiv3 11y ago

The idea of spreading a leap second over a longer period is not unique to Google e.g. www.quadibloc.com/science/cal06.htm The idea itself is actually rather obvious.

jpatokal 11y ago
Most good ideas are obvious in hindsight. ;) But AFAIK, Google was the first to do this live and in production by hacking NTP, which is (apparently?) the same as what Amazon is doing.
- chronial 11y ago
  SAP Systems have been doing this for many, many years live and in production for DST adjustments. Not sure about leap seconds.
  - RedNifre 11y ago
    What? How does it make sense to spread DST adjustments over a long time?
    - Namrog84 11y ago
      What if in a dst jump. It had. Pay namrog84 $100 at 1:30am. Then 2 rolls around and it's 1am again and now I get paid a second time. Win! But if dst was smeared over a day. This would be easily prevented.
fanf2 11y ago
See also Markus Kuhn's description of smoothed leap seconds from 2005: https://www.cl.cam.ac.uk/~mgk25/time/utc-sls/ https://www.cl.cam.ac.uk/~mgk25/time/utc-sls/
a-priori 11y ago
The time-smearing technique reminds me of how the Erlang platform (ERTS) adjusts its internal timekeeping to changes in the system's clock. If the system's clock jumps, then Erlang makes its internal clock tick faster or slower than the system's clock by at most 1% in order to resynchronize. http://www.erlang.org/doc/apps/erts/time_correction.html http://www.erlang.org/doc/apps/erts/time_correction.html

acqq 11y ago

It looks to me AWS is using the different algorithm. See my other comment here.

Terretta 11y ago

Google didn't come up with that first. I'm aware of a number companies with multiple data enters (my last co had 14 around the world) and coordinated logs or time sensitive services that used this technique. I personally implemented it 12 years ago, to support (a) a kind of geo-balancing based on time coordinated spoofed DNS responses, and (b) time stamped URL token expiration validation, sensitive to seconds, across distributed datacenters. I got the idea from Microsoft Windows' ability to drift the clock back into sync. Google has adopted or reinvented a lot, and gets credit because they have extra time and resources to publish. // TBC, they also invented a lot. But not this one. Sibling comments point out other implementations predating Google as well.

deleted 11y ago

[deleted]