[LEAPSECS] Do lawyers care (know) about leap seconds?

[Steffen Nurpmeso]

Warner Losh <imp at bsdimp.com> wrote:
 |On Oct 1, 2014, at 10:15 AM, Tony Finch <dot at dotat.at> wrote:
 |> Steffen Nurpmeso <sdaoden at yandex.com> wrote:
 |>> I cannot imagine you wouldn't agree that having CLOCK_TAI (and
 |>> CLOCK_LEAPDRIFT) make things easier.
 |> 
 |> For most purposes we need civil time, and a TAI clock doesn't solve the
 |> problem that civil time is too difficult to get right.
 |
 |The “just use a different timescale” argument never will have much traction
 |until the primary timescale is implemented correctly, robustly \
 |and universally.
 |UTC isn’t today.

No.  The missing traction is that i as a user-space programmer
only have access to a normalized artificial clock that has leap
seconds incorporated.  I do not even have access to a table of
leap seconds through any official interface, in order to redo that
normalization (which is a very complicated and expensive task even
otherwise).  As a person bound to standard interfaces i'm blind,
deaf and dumb regarding the clock.

Things would be completely different if there would be CLOCK_TAI
(and CLOCK_LEAPDRIFT), and any computer that uses NTP has in
theory easy access to all the necessary data, but unfortunately
that is thrown away before it hits the wire.

I'm not gonna argue UTC is a shitty timescale as i don't know, it
may be, but i'm happy it is 12:10:04+0200 right now etc., nor do
i condemn RFC 5905's "A primary server is synchronized to
a reference clock directly traceable to UTC (e.g., GPS, Galileo,
etc.)" (the following 104 pages of this document may be the
problem instead), in the end it is a time-protocol and that's what
it delivers, but i'd wish it would also deliver me with eight more
bytes of information that it itself readily has available, or
maybe 12 (though 48:16 bits should instead be sufficient for quite
some time too).
Nothing more, nothing less.
But especially not: throw overboard an entire timescale.
That's not what i intend.

--steffen