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 <[email protected]> wrote: > -------- > In message <[email protected]>, 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 > [email protected] | 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 > [email protected] > https://pairlist6.pair.net/mailman/listinfo/leapsecs _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
