REMINDER: Leap Second

Sun Jan 25 17:26:27 UTC 2015

I think devices would likely be fine, unless they're concerned with reconciling
a leap-second updated ntp source and one that's not. Who wins? 

For most NTPs I would guess they're slaves to whatever feed and just 'believe'
whatever they're told. (Sounds like a security hole waiting for high frequency
trader types, q.v.
http://www.theverge.com/2013/10/3/4798542/whats-faster-than-a-light-speed-trade-inside-the-sketchy-world-of
)

Can't we just subscribe to a leapsmeary NTP feed if we care to have no
big leap (I dont mind)? Isnt NIST offering this?

/kc

On Sun, Jan 25, 2015 at 06:01:40PM +0100, Karsten Elfenbein said:
  >Hi,
  >
  >Java had some issues with 100% CPU usage when NTP was running during
  >the additional second in 2012.
  >http://blog.wpkg.org/2012/07/01/java-leap-second-bug-30-june-1-july-2012-fix/
  >
  >Google did something different to get the extra second in:
  >http://googleblog.blogspot.de/2011/09/time-technology-and-leaping-seconds.html
  >
  >Most devices probably don't even know about the leap second coming as
  >that would require a firmware upgrade.
  >
  >
  >Karsten
  >
  >2015-01-25 16:19 GMT+01:00 Mike. <the.lists at mgm51.com>:
  >> On 1/25/2015 at 9:37 AM Jay Ashworth wrote:
  >>
  >> |This June 30th, 235959UTC will be followed immediately by 235960UTC.
  >> |
  >> |What will /your/ devices do?
  >>  =============
  >>
  >>
  >> I've always wondered why this is such a big issue, and why it's done
  >> as it is.
  >>
  >> In UNIX, for instance, time is measured as the number of seconds
  >> since the UNIX epoch.  imo, the counting of the number of seconds
  >> should not be "adjusted", unless there's a time warp of some sort.
  >> The leap second adjustment should be in the display of the time,
  >> i.e., similar to how time zones are handled.
  >>
  >>
  >> fwiw
  >>
  >>
  >>

-- 
Ken Chase - math at sizone.org Toronto