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