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 >> critical. > > The challenge here is that the broadcast industry needs fixed-epoch > deterministic local timescales to accomplish media (video and audio) > timekeeping. >[...] > 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. _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
