[LEAPSECS] Bloomberg announced its smear
scs+ls at eskimo.com
Sat Sep 24 17:32:02 EDT 2016
Brooks Harris wrote:
> On 2016-09-24 11:39 AM, Stephen Scott wrote:
>> Smearing is fine if you don't depend on a second being a second.
>> I work in the broadcast industry where time synchronization is
> The challenge here is that the broadcast industry needs fixed-epoch
> deterministic local timescales to accomplish media (video and audio)
> Fundamentally, the early implementations of POSIX and the many systems
> based on its heritage cannot represent "23:59:60" and so most systems
> are *indeterminate* at (or near) the Leap Second.
Right. I think several things are clear:
* Most code assumes Posix (warts and all) and needs the Posix
definition preserved, and can tolerate smearing perfectly fine.
* Some code needs more perfect timekeeping, with perfectly
accurate seconds, and/or explicitly visible leap seconds,
and therefore definitely no smearing. (See also RFC 7164.)
* The typical "fallback" Posix implementation, which does
something variously ill-defined, nondeterministic, and/or
jumpy at a leap second, is really pretty unacceptable.
(Yet that's what most systems are still living with today.)
My conclusion is that there's no One True Solution. My hope
(and I'm trying to arrange a demonstration) is that it's possible
to implement some decent compromises, preserving Posix (with
possible smearing) for the majority of programs that need it,
providing true UTC for the few programs that need it, and
absolutely getting rid of any awkward clock jumps at UTC midnight
on leapsecond days.
More information about the LEAPSECS