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

[Adrian Godwin]

I was inclined to agree, cynically reasoning that many implementations
would argue that the leapseconds would average out in most applications and
they could ignore them.

But actually, it would be good for programmers to properly separate the
concepts of elapsed time and clock-time. If elapsed time were handled by
kernels and clock-time handled by a user-mode UTC or calendar process, that
would be a cleaner solution with overhead only where needed (or where the
OS is big enough for it to be a trivial element).


As a side issue, what would be the impact of having frequent
leap-milliseconds instead of infrequent leap-seconds ?

On Thu, Jul 21, 2016 at 8:53 PM, Steve Allen <sla at ucolick.org> 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.  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.
>
> 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.
>
> --
> Steve Allen                    <sla at ucolick.org>              WGS-84 (GPS)
> UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat
> +36.99855
> 1156 High Street               Voice: +1 831 459 3046         Lng
> -122.06015
> Santa Cruz, CA 95064           http://www.ucolick.org/~sla/   Hgt +250 m
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>