[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Leap Second planned for 2016
- Subject: Leap Second planned for 2016
- From: swmike at swm.pp.se (Mikael Abrahamsson)
- Date: Sun, 10 Jul 2016 18:37:02 +0200 (CEST)
- In-reply-to: <CAAeewD-p8w5M5neGMtT8qkE=2sBNyn2wUWUOqT22+31R_cmUig@mail.gmail.com>
- 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]> <CAAeewD-p8w5M5neGMtT8qkE=2sBNyn2wUWUOqT22+31R_cmUig@mail.gmail.com>
On Sun, 10 Jul 2016, Saku Ytti wrote:
> 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?
Since one problem is that the leap second code isn't exercised regularily,
I propose that each month there is a leap second either forward or
backward. These forward/backward motions should be fudged to over time
make sure that we stay pretty much correct.
If POSIX needs to be changed, then change it. By making leap second not a
rare event, this would hopefully mean it'll get taken more serously and
the code would receive wider testing than today.
--
Mikael Abrahamsson email: swmike at swm.pp.se