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-tr... ) 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.ht...
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@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@sizone.org Toronto