Can honoring of daylight savings time be d
guy at netapp.com
Thu Dec 8 19:37:53 UTC 1994
> Doug Gwyn <gwyn at arl.mil> writes:
> > UNIX "system time" is *unaffected* by Daylight
> > Saving Time; it always counts clock ticks since a fixed epoch, which
> > progresses unformly regardless of legislative actions. The mapping to/from
> > human-being time is performed by library functions that can be instructed
> > as to the exact rules to be applied
> Do you believe this concept should be extended to leap seconds?
I'd certainly vote that way.
> The `ado' time package proves such an extension is feasible. (The only
> slight problem I've seen in practice is with programs that assume every
> minute has 60 seconds.)
ANSI C made an effort to allow minutes with more than 60 seconds (Doug
may even have been the one who pushed them to do that), although, as you
> However, POSIX seems to legislate the possibility away,
As I remember, the POSIX people seemed just to be confused; I never
heard anything from them indicating that they actually understood the
issue. The POSIX spec says
Most systems' notion of "time" is that of a
continuously-increasing value, so this value should increase
even during leap seconds.
So, far, so good - that's 100% correct - but they then go on to say:
However, not only do most systems not keep track of leap
which is true only because, at the time POSIX was published, most
UNIX systems didn't have the Olson code.
I.e., there was no rocket science involved with *making* UNIX systems
handle leap seconds - the system supplier just had to pick up the code
you wrote and the tables. Unfortunately, POSIX's erroneous decision
gave a strong incentive *not* to do so....
...but most systems are probably not synchronized to any
standard time reference. Therefore, it is inappropriate to
require that a time represented as seconds since the Epoch
precisely represent the number of seconds between the reference
time and the Epoch.
which is certainly correct, but, as I remember, I presented precisely
that argument in an attempt to get POSIX to *ALLOW* leap-seconds to be
used - i.e., given that most systems aren't synchronized, worrying about
a few leap seconds in those systems is silly and shouldn't be used to
justify forbidding a system to keep track of them, and, on those systems
that *are* synchronized, you probably *want* to keep track of leap
They then proceed with:
It is important that the interpretation of time names and
"seconds since the Epoch" values be consistent across conforming
systems. That is, it is important that all conforming systems
interpret "536 457 599 seconds since the Epoch" as 59 seconds,
59 minutes, 23 hours 31 December 1986, regardless of the
system's idea of the current time. The expression is given to
assure a consistent interpretation, not to attempt to specify
the calendar. The relationship between "tm_yday" and the day of
week, day of month, and month is presumed to be specified
elsewhere, and not given in this standard.
Consistent interpretation of "seconds since the Epoch" can be
critical to certain types of distributed applications that rely
on such timestamps to synchronize events. The accrual of leap
seconds in a time standard is not predictable. The number of
leap seconds since the Epoch will likely increase.
Such distributed applications, I suspect, don't give a damn whether
"536 457 599 seconds since the Epoch" is 31 December 1986 23:59:59 or
not; I suspect they largely deal only in "units of time since some
standard epoch" values, not in those peculiar labels that humans insist
on using to designate instants of time. If any *do* care, I suspect
they could be fixed not to care.
I.e., the only places I'd expect the behavior of "localtime()" and
"mktime()" and "gmtime()" and company with respect to leap seconds to be
1) when interacting with human beings, i.e. printing out times
or writing them in human-readable form to a file, or reading
them from what some person types in - but I suspect the only
effect on humans would be very occasional confusion if the
human happens to say "date" and it calls "time()" when the
leap second is in progress and prints out a date value like
2) when interacting with some time source that deals in
human-style time labels rather than time units since some
epoch - but either
1) that time source knows about leap seconds, in which
case it might be a *good* thing for "localtime",
"gmtime()", "mktime()", and company to take leap
seconds into account;
2) that time source *doesn't* know about leap seconds,
in which case it's probably off by a few seconds, and
the fact that "localtime()" or "mktime()" or
"gmtime()" produce labels that are off by a few
seconds probably doesn't matter anyway.
> and the NTP
> implementors seem to favour a complex system that jumps the clock.
I may be misreading the spec, but, given that the NTP V3 timestamps are,
in fact, represented as time units since some epoch (2^-32-seconds since
00:00:00 UTC January 1 1900, as I read the spec), I think the whole
point of leap seconds in NTP V3 is to inform NTP clients that, when
converting time-units-since-some-epoch time stamps to human-style
labels, the scale used to do such conversion will shift.
In particular, they correctly note that
The insertion of leap seconds in UTC and subsequently into NTP
does not affect the UTC or NTP oscillator, only the conversion
to conventional civil UTC time.
The UNIX clock is assumed to track the UTC or NTP oscillator, i.e. to
start at 0 at some particular UTC value, and go up by 1 every time the
oscillator goes up by some value of N. "gmtime()" is the routine that
converts the UNIX clock to "conventional civil UTC time", as I
I.e., I suspect that they're trying to cope with systems that don't know
how to take leap seconds into account when converting timestamp-style
clocks to "conventional civil time"; however, as UNIX systems with the
Olson code including your leap-second code, and with timezone files
containing correct leap-second data, *do* know how to take leap seconds
into account while doing so (even if they risk the wrath of the
Institute of Electrical and Electronic Engineers in doing so).
More information about the tz