[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Leap Second planned for 2016
- Subject: Leap Second planned for 2016
- From: saku at ytti.fi (Saku Ytti)
- Date: Sun, 10 Jul 2016 11:27:33 +0300
- In-reply-to: <[email protected]>
- References: <[email protected]> <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com> <[email protected]> <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com> <[email protected]> <CAAeewD9LXBngWYT-RZJhC-oP7O2=BEDDjiQMmqWYJeKyyTgiUw@mail.gmail.com> <[email protected]>
On 10 July 2016 at 00:12, <Valdis.Kletnieks at 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