[time-nuts] [LEAPSECS] Leap second to be introduced at midnight UTC December 31 this year

Oz-in-DFW lists at ozindfw.net
Thu Jul 21 18:48:53 EDT 2016


On 7/21/2016 2:53 PM, Steve Allen wrote:
> On Thu 2016-07-21T10:27:57 -0700, Tom Van Baak hath writ:
>> Time to mention this again...
>> Every UTC-aware device would 1) know how to reliably insert or
>> delete a leap second, because bugs would be found by developers within
>> a month or two, not by end-users years or decades in the future, and
>> 2) every UTC-aware device would have an often tested direct or
>> indirect path to IERS to know what the sign of the leap second will be
>> for the current month.
> This idea pushes extra complexity into every implementation of low
> level kernel-space software, firmware, and hardware.  
Why?  That would only seem to be true if the leap second decision is
already made there.  Most systems I'm aware do this in presentation
level firmware.
> That's nice as a
> policy for full employment of programmers, but it's hard to justify by
> any other metric.  Instead those low level places should be as simple
> as possible, and that means making the underlying precision time
> scale, and thus any broadcast distributions of a precision time scale,
> as simple as possible.
I think I understand what you are saying, but I'm pretty sure I
disagree.  The vast majority of complexity (and risk) of most software
and testing comes from exceptions and making sure all combinations are
tested. In this case the exception is simplified.  You still need to
detect end of month, but you have regular logic to implement. As a
practical matter this should be easier to code as a fixed time of
execution operation.
> The complexity for translating precision time in seconds (for
> machines) to calendar time in days (for humans) belongs in the
> less-critical and easier-testable outer layers of software which do
> user-space presentation, internationalization, and GUI which can be
> broadly shared between many hardware implementations.
I agree for the most part.  Complexity should be driven as high in the
layer stack as practical.  What about this proposal requires changes
from the place it is already done in a particular system? 

-- 
mailto:oz at ozindfw.net    
Oz
POB 93167 
Southlake, TX 76092 (Near DFW Airport) 





More information about the time-nuts mailing list