[LEAPSECS] Schedule for success

[M. Warner Losh]

In message: <m3bpv4with.fsf at lugabout.jhcloos.org>
            James Cloos <cloos+leapsecs at jhcloos.com> writes:

: My point is that the majority of systems which care about timing and

: which can not get almanac data to correlate an interval since an epoch

: with human time-of-day do not, in general, really need the latter.


I see that you've stated this point, but I don't think it is valid.
There's very few timing systems that don't care about UTC at some
point.  And those are the only systems that care about something other
than UTC.

In general, all systems need to be synchronized to human time because
at some point they have to interact with humans.  As long as we have a
time scale that is irregular, there are going to be problems.

People readily poo-poo the off-by-one-second issue with leap seconds,
but I can assure you as someone who has a lot of software experience,
that in both timing and non-timing applications people care a lot
about that.  Sure, it usually doesn't matter much, and you can usually
get away with it, but that reason alone is not sufficient to say it is
never a problem.

Finally, I say 'human time' here for a reason.  The only reason I care
that it is 9:11am as I type this is because my son has a hockey game
at 1:30pm today, my friends are coming over for dinner at 6:00, etc.
The solar time locally is about 20 minutes different than these times,
and that concerns me not at all.  The authorities said the time right
now is 9:11am and everybody agrees with to use that time, I'm happy
with it.  That's the important part of the current system: everybody
agreeing on what time it is.  That's why I tolerate the current
dysfunctional leap second system, but want to make it better.

Since I'm already divorced from local solar time, and seconds aren't
based on this year's mean solar day, I find it a quaint throwback to
have leap seconds at all.  Since we can measure and publish the drift,
why bother with all the hair of leap seconds?  They are at best a
short-term kludge until we find something better.  Since we've only
been using them for 40 years, there's no real posterity to worry
about.  Since we're going to have to have them with increasing
regularity over the next 50 years, to the point where 2 a year are
unlikely to be enough, we need to ask ourselves if there's some better
way to distribute time than what we're doing.  We should learn from
our experiences with leap seconds and adjust the system to something
that works better.  When leap seconds started, there was no Internet,
and there were maybe a hundred people in the world that were affected
by them and needed to get them right.  Now that the world is
interconnected, and ntpd still can't seem to get them right on all the
computers running it (in part due to well meaning people causing
problems with rubber seconds around the leap event), I think that
experience has shown that the system needs to be reegineered.

Warner