FW: Mass media article on leap seconds

Olson, Arthur David (NIH/NCI) olsona at dc37a.nci.nih.gov
Wed Mar 10 19:46:49 UTC 2004

The message below was not forwarded to the list last week since
it came from Bradley White's new address; Bradley is now on the list
under the new address.


------- Begin Forwarded Message
Date: Tue, 02 Mar 2004 12:08:40 -0500 (EST)
From: Bradley White <bww at acm.org>
Subject: Re: Mass media article on leap seconds
To: Zone Watchers <tz at lecserver.nci.nih.gov>
In-Reply-To: Markus' message of Tue, 02 Mar 2004 16:17:48 +0000

ado wrote:
> Your correspondent's two cents: in setting up the time handling in
> got it exactly right with respect to springing forward and falling
back when
> DST goes in to and out of effect--keep the computer counting
> and leave it to the software to translate the monotonic count into a
> representation of local time. What's right at the level of an hour is
> right at the level of a second--keep the computer counting at one
count per
> second, and leave it to software to figure out what should be
displayed when
> the user asks what time it is.

Markus replied:
> I don't agree. There is the important difference that UTC is today
> widely disseminated, whereas TAI is a curiosity only known to time
> like us. Keeping a computer synched to something like TAI would only
> practical in the real world if a leap-free timescale (e.g., the
> TAI or GPS time) were widely enough available, along with a regularly
> updated UTC-TAI offset table. Current time distribution services,
> however, provide only UTC in easily accessible form, therefore running
> machines in TAI would likely cause them to get the leap second offsets
> wrong due to out-of-date leap-second tables rather quickly. Their
> timestamps would quickly get an integer number of seconds wrong
> to the timestamps of machines with up-to-date leapsecond tables.

I disagree with your disagreement.  I ran machines using ado
mode and synchronized by NTP, and they sailed smoothly through leaps
no fudging.  The NTP code was modified to ignore leap warnings, and to
a single call to time2posix().  If those machines still existed they
still be synchronized no matter whether their leapsecond tables were up-
to-date or not (although they would hiccup over leaps they were unaware

Part of the problem might be in what you refer to as "timestamps".  An
ado 'right_only' system certainly doesn't believe that its raw time_t is
a form useful as an external representation.


------- End Forwarded Message

More information about the tz mailing list