[LEAPSECS] Look Before You Leap – The Coming Leap Second and AWS | Hacker News

[Stephen Colebourne]

Standards are funny things. Sometimes they get adopted and sometimes
they don't. Sometimes more than one standard becomes the standard.

The leap seconds debate exists because there are two entirely
reasonable ways to talk about time, one based on the sun and one based
on atomic clocks. The solar form has, over thousands of years, created
the view that there are always 86400 seconds in a day, ignoring DST.
Given this, API writers like my self (Java) have no choice but to
provide developers with an API view where there is never ever an
instant where second-of-day = 60. Developers, like most humans, prefer
the fiction that every day has 86400 subdivisions called seconds,
whether true or not. From my perspective, the unwillingness to accept
or create a UT-86400 time scale, and define its link to UTC, is very
problematic. I also think it is the root of a solution to this sorry
saga.

Stephen


On 19 May 2015 at 17:05, Warner Losh <imp at bsdimp.com> wrote:
> One has to wonder, though. UTC is the standard. Why do we need another
> standard to subvert the original standard if the original standard were easy
> to implement correctly? Surely the existence of these ‘smeared’ timescales
> points to a fundamental flaw in the method we’ve chosen to keep atomic
> and solar time in sync?
>
> Warner
>
>> On May 19, 2015, at 2:10 AM, Stephen Colebourne <scolebourne at joda.org> wrote:
>>
>> A key point I've been making all along is that there needs to be an
>> internationally agreed standard for how to do the smoothing. In Java I
>> recommended UTC-SLS simply because it was at least a written up
>> approach. (My preference is for a linear change because there is less
>> chance of implementors getting it wrong).
>>
>> We would also need an agreed name for a time-scale that is aligned
>> with UTC most of the time but that always has 86400 subdivisions of
>> the day (rubber seconds). The lack of a name for this (something which
>> I strongly believe is desired) is very frustrating. I'd suggest
>> UT-86400 as a starting point for a name.
>>
>> Stephen
>>
>>
>>
>> On 19 May 2015 at 07:20, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>>> --------
>>> In message <DCE2E991-A54D-42AF-98F8-2D5087FBFB9E at leapsecond.com>, Tom Van Baak writes:
>>>
>>>
>>>> https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/
>>>
>>> So already here the trouble starts:  Google uses a smooth curve for their clock-smearing
>>> and Amazon uses a piecewise linear curve.
>>>
>>> I can see reasons for both choices, but I'd probably go with Googles
>>> to avoid the sharp corners.
>>>
>>>
>>> --
>>> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>>> phk at FreeBSD.ORG         | TCP/IP since RFC 956
>>> FreeBSD committer       | BSD since 4.3-tahoe
>>> Never attribute to malice what can adequately be explained by incompetence.
>>> _______________________________________________
>>> LEAPSECS mailing list
>>> LEAPSECS at leapsecond.com
>>> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>> _______________________________________________
>> LEAPSECS mailing list
>> LEAPSECS at leapsecond.com
>> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>