Re: Leap Second planned for 2016

[Saku Ytti <saku () ytti fi>]

On 10 July 2016 at 00:12,  <Valdis.Kletnieks () vt edu> wrote:
> It doesn't help that the POSIX standard doesn't represent leap seconds
> anyplace, so any elapsed time calculation that crosses a leap second
> is guaranteed to be wrong....

So how can we solve the problem? Immediately and long term?

a) use UTC or unix time, and accept that code is broken
b) migrate to CLOCK_MONOTONIC, and accept that epoch is unknown (you
cannot serialise clock and consume it in another system)
c) use NTP smear to make clocks run incorrectly to hide the problem
d) use GPSTIME or TAI and implement leaps at last possible moment (at
the presentation layer)
e) wait for 2023 and hope the problem goes away

-- 
  ++ytti