Can honoring of daylight savings time be d

[Guy Harris]

> 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
note:

> 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
	seconds...

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....

They continue:

	...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
seconds!

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
relevant are:

	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
	   "12:30:61".

	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
understand it.

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).