[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Leap Second planned for 2016
- Subject: Leap Second planned for 2016
- From: patrick at ianai.net (Patrick W. Gilmore)
- Date: Fri, 8 Jul 2016 21:39:32 -0400
- In-reply-to: <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com>
- References: <[email protected]> <CA+M5dWbZM1kQx1dG6Ba_cEYOyH=f9X5vhuc6bmM6s8pCdbGx=g@mail.gmail.com> <[email protected]> <CAAeewD_kxj2g4=XaNk8jj5DCp8hEhtNY5JhAQesCyYGVy8Opew@mail.gmail.com>
On Jul 8, 2016, at 7:47 PM, Saku Ytti <saku at ytti.fi> wrote:
> On 9 July 2016 at 02:27, Jared Mauch <jared at puck.nether.net> wrote:
>> Time is actually harder than it seems. Many bits of software break in unexpected ways. Expect the unexpected.
>
> Aye. How many have written code like this:
>
> start = time();
> do_something();
> elapsed = time() - start;
>
> Virtually all code dealing with passage of time assumes time moves
> only forward, I'm amazed we don't see more issues during leap seconds.
> Portable monotonic time isn't even available in many languages
> standard libraries.
>
> Hopefully they'll decide in 2023 finally to get rid of leap seconds
> from UTC. Then GPS_TIME, TAI and UTC are all same with different
> static offset.
But time _DOES_ flow. The seconds count
58, 59, 60, 00, 01, ?
If you can?t keep up, that?s not UTC?s fault.
As for stopping the leap seconds, talk to the planet Earth. It?s the one who will not conveniently rotate properly. Either that, or run REEEEEEALLY Fast in that -> direction every once in a while. :-)
--
TTFN,
patrick