[LEAPSECS] internet drafts about zoneinfo (POSIX Time)
Joseph M Gwinn
gwinn at raytheon.com
Tue Mar 8 12:08:45 EST 2011
Kieth,
leapsecs-bounces at leapsecond.com wrote on 03/07/2011 10:04:02 PM:
> From:
>
> Keith Winstein <keithw at MIT.EDU>
>
> To:
>
> Leap Second Discussion List <leapsecs at leapsecond.com>
>
> Date:
>
> 03/07/2011 10:04 PM
>
> Subject:
>
> Re: [LEAPSECS] internet drafts about zoneinfo
>
> Sent by:
>
> leapsecs-bounces at leapsecond.com
>
> On Mon, 7 Mar 2011, Joe Gwinn wrote:
>
> > Yes, POSIX does have a progress rule. It adds one second per SI
second to
> > the Seconds Since the Epoch counter, and converts this count to
something
> > resembling UTC (but having no leap seconds).
>
> Hi Joe,
>
> If I understand you correctly, this is just not right. POSIX
> does not add
> one second per SI second to the time_t counter. E.g., between UTC
> 12-31-2005 23:59:59 and UTC 1-1-2005 00:00:00, there were two
> SI seconds.
> A POSIX system's gettimeofday() only increased tp->tv_sec by 1.
The definition of a SI second does not depend on UTC, even though UTC uses
SI seconds.
You are right that POSIX explicitly ignores leap seconds, as stated in the
standard. (In practice, if one uses NTP to synchronize to UTC, a
POSIX-compliant computer will follow leap seconds more-or-less dutifully,
never mind the standard.
I guess that "one second per SI second" wasn't precise enough.
> Here are the relevant excerpts from SUS:
>
> XXX
>
> If the year is >=1970 and the value is non-negative, the value
> is related
> to a Coordinated Universal Time name according to the C-language
> expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all
> integer types:
>
> tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
> (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
> ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400
>
> The relationship between the actual time of day and the currentvalue for
> seconds since the Epoch is unspecified.
>
> How any changes to the value of seconds since the Epoch are
> made to align
> to a desired relationship with the current actual time is
> implementation-defined.
Yep.
> Most systems' notion of "time" is that of a continuously
> increasing value,
> so this value should increase even during leap seconds.
>
> XXX
>
> Note that as a practical consequence of this, the length of a second as
> measured by some external standard is not specified. This unspecified
> second is nominally equal to an International System (SI) second in
> duration. Applications must be matched to a system that provides the
> particular handling of external time in the way required by the
> application.
This was as close to declaring that POSIX seconds are SI seconds (to the
accuracy of the local clock) as I could get the committee to go. While
most agreed that this was at least nominally so, the issue was that if we
say that these are SI seconds, some customer will complain saying that the
computer's built-in clock hardware doesn't achieve this (for lack of
sufficient accuracy and/or stability).
Given that 99% of computer buyers never heard of SI seconds, which is why
the clock oscillators in computers often make better thermometers than
clocks, this seems to me to be a reasonable position. It is expected that
those who do know and care will buy the needed special hardware.
Joe Gwinn
More information about the LEAPSECS
mailing list