[LEAPSECS] Look Before You Leap – The Coming Leap Second and AWS | Hacker News
Stephen Colebourne
scolebourne at joda.org
Tue May 19 04:10:25 EDT 2015
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
More information about the LEAPSECS
mailing list