Re: [PATCHv2] Add support for leap seconds in zoneinfo files

[Rich Felker <dalias@aerifal.cx>]

On Fri, Dec 06, 2013 at 11:29:33PM +0000, Laurent Bercot wrote:
> On 06/12/2013 11:38, Raphael Cohn wrote:
> 
> >I'm not sure I've completely followed all the ramifications here.
> > Why should one have to restart processes on 1,000s of nodes
> > for something like this? 5 9s contracts are hard enough to satisfy
> > at the best of times, without adding another 30 - 120 seconds of
> > restart impact, degraded performance and failover for large jobs.
> > In the sorts of sites we operate in, there might be just one admin
> > for the entire estate, and they're busy enough, and probably laden
> > down with more special knowledge than they can recall as it is, to
> > have to deal with something like this as well...
> 
>  The recent rate of leap seconds announcements has been about one
> every three years. Firmware, and even hardware, evolves faster than that.
> In three years, you probably have had to update your production image at
> least once. Including new leap second tables into it would basically have
> been free.
>  And even if you have to do a restart *specifically* for this thing,
> if you are dealing with thousands of nodes and need to provide five nines,
> then you have good enough automation to reboot your machines one after
> the other by snapping your fingers and without making a dent in the
> quality of your service.

What I'm missing is the benefit. The only benefit I can see to using
TAI-10 is that you're synchronizing with your chosen clock source over
years/decades with no discontinuity. If you're willing to accept a
discontinuity every few years, why not just use plain POSIX time and
apply the new difference between TAI-10 and POSIX time when rebooting?

>  Restarting a process is cheap and easy, should be a standard tool in your
> toolbox, and your workflow should make use of it when it's needed. You
> don't get high availability by forbidding your processes to die: you get
> high availability by making sure it's not a problem when they die.

I think this is an area where you'll find you're coming from a
fundamentally different philosophy than most of the musl folks. The
way I interpret your position is that using TAI-10 is only suitable
for managed desktop/server systems, not any other kind of use where
there's no system operator who's aware of leap second announcements
and capable of doing manual upgrasdes. (And having system scripts kill
and restart processes behind your back to do this for you is even
worse; that's akin to the way Windows automatically reboots behind
your back, and users hate it.)

> >Date and time match has been got wrong in every system
> >(...)
> >Personally, I think apps should just use a monotonic source of seconds
> > from an epoch, and use a well-developed third party lib dedicated to
> > the problem if they need date math (eg Joda time in Java).
> 
>  I absolutely agree with you on the first part. I disagree on the second
> part. Dealing with time shouldn't be a burden on the application - devs
> have other things to think about, and experience shows that most of them
> won't care, they'll just use the primitives provided by the system. So,
> the system should do the right thing, i.e. provide something that works
> no matter how applications are using it. Here, it means providing a
> linear CLOCK_REALTIME, because people use it as if it were CLOCK_MONOTONIC.

If that's your only goal, it's easily achieved without storing TAI-10
in the CLOCK_REALTIME clock, assuming by "linear" you just mean
"monotonic, continuous, and accurate within the margin of measurement
error". Discontinuous jumps and non-monotonicity in CLOCK_REALTIME
were a monstrosity invented by the NTPD folks in their implementation
for mapping TAI onto POSIX time, not any fundamental requirement.

Rich