[LEAPSECS] (no subject)

[M. Warner Losh]

In message: <8D831340-BE80-4595-9E73-EAA3465A41B6 at ucolick.org>
            Steve Allen <sla at ucolick.org> writes:

: 

: On 2008 Dec 20, at 10:55, M. Warner Losh wrote:

: > Either we kill them entirely, since they are going away eventually

: > anyway, or we put them on a regular schedule like leap years.  The

: > current system sucks too bad to be allowed to continue.

: 

: Pardon me, but I'm missing something in this about the annoyance

: of leap seconds.  I thought the trouble was that they interrupt the

: broadcast time scale (which I distinguish from UTC).


That's one of many problems.


: If the ITU-R decides to bless a new time scale like TI, then POSIX

: can take note and say as of then time_t is to be interpreted as the

: internationally-blessed broadcast time scale named TI.  Bureacracy

: that happens to have specified UTC can be reinterpreted on a case

: by case basis to decide whether it wants TI or UTC, but in the

: interim all the operational systems keep on working.


I'd have to think about this carefully to make sure that it would
work, but there's still at least one problem if UTC is still around...


: If leap seconds go into zoneinfo, then they are only as much nuisance

: as when the political princes of the world decree a change in the

: rules for time zones, and not even total unanimity within the ITU can

: stop that.


There's three issues with this.  First, long running programs
(programs that run for years) will force the libraries that cope with
these files to stat them from time to time to make sure that there
isn't a new update (otherwise your time will be 1s off).  Second, many
programs need to run over leap seconds still and behave properly.
Third, you never know if you have the right, up to date files when you
startup (think systems that are cold spares that have been on the
shelf for a year).  How do you reconcile that?

Also, there's silly operational things like "how do I update these
files if there's no vendor to update them?" which is a matter of
programming.  And do I let anybody update them?  What if my GPS
control program wants to do it?  What if ntpd wants to do it (assuming
it goes to TI)?  What if they both want to do it and the data are
unconsistent?  You still have to figure out who to believe in this
case.

And what's the recommended SOP for dealing with systems that learn
that the current offset is 42 seconds, but the leap files only have 34
seconds listed?  Is there a "good enough" standard for "interpolating"
when these leap seconds could have happened and updates to the tables
happen that way?

And what about network protocols that still need to report UTC times
rather than these new TI times for things like file modification time
(say, NFS)?  Since these are implemented in the kernel, now you have
to give the kernel a reasonable table.  And since timestamps span a
number of years, the question about putative leap seconds from the
previous paragraph doesn't sound so funny.  People likely won't care
too much if the timestamps are off a few seconds, but things like
'make' will care (if your sources are on a NFS server and your objects
are on local storage).

Oh, and likely a dozen other issues I've not thought of off the top of
my head.  At least with UTC, everybody botches leap seconds, but also
the broadcast of time is deterministic.  If you broadcast time that's
offset, and rely on tables in the receiving device, then you lose some
of that because of the problem of stale tables (or worse, wrong ones).


: I agree that the current system is dysfunctional.


Yea!


: I typically carry around 100 GB of storage, a GHz of processing

: capability, and devices that can communicate with 4 different

: wireless protocols.  That is how the world has changed since 1970

: when everything was pencil, paper, and slide rule.  My devices can

: receive something like TI, use it internally, and report to me something

: with added timezone offsets.


Right.  However, many of these systems that I'm used to dealing with
aren't connected to a meaningful network at all.  Most of these
systems have 100-300 MHz of power, ~100MB of storage (or less), and
limited connectivity.  Often times they just know the current offset
(and that only after 30 minutes in a cold start case for gear that's
been on the shelf for a while).  Since their purpose is to display in
UTC and interact with gear that uses UTC, plus weather a leap second
w/o having a step in their internal time representation (which, btw,
has to be efficient in storage and arithmetic operations done on it,
which makes 'broken down UTC time + leap tables' a non-starter, so a
count of SI seconds since some epoch is usually used, with the
conversions to UTC done for display, which means to do any display,
you have to know the right number of leap seconds).


: But of those wireless protocols, one of them was entirely shut down

: by the FCC before I had owned the device 5 years, so that one is defunct

: and the hardware deserves replacement.

: 

: I don't want to see mean solar time abandoned because of the  

: shortcomings of systems with that sort of lifetime.


But mean solar time already has been abandoned.  The second isn't
1/86400th of a mean solar day anymore, so although it was originally
meant to measure a rotational angle of this spinning rock, we've
changed the units so that it no longer does that.  Leap seconds are at
best a kludge until something better comes along, or until the length
of day is 86401 SI seconds long...

Warner