Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.bugs.4bsd
Subject: Re: Leap seconds
Message-ID: <39048@sun.uucp>
Date: 15 Jan 88 21:04:10 GMT
References: <7622@alice.UUCP>
Sender: news@sun.uucp
Lines: 43

> So where did the leap seconds go?  One way to think of the situation is
> that the epoch (and in fact all times before the leap second) moves
> whenever we have a leap second.

Unfortunately, this is inconsistent with the wording in POSIX Draft 12, wherein
it states that "The Epoch refers to the time at 0 hours, 0 minutes, 0 seconds,
Coordinated Universal Time on January 1, 1970."  There is only one such
instant; it can't move.

If the POSIX spec *meant* to say that, when converting "time_t" to "struct tm",
the conversion code should act *as if* leap seconds weren't counted in the
result of "time()" (even though they are, unless you stop your clock during
leap seconds), it should say so - which means this should be described in
Chapter 8, the section where additional information about C language library
routines is presented.

I still think that all efforts to work hard at interpreting the POSIX document
in an unusual manner so as to permit existing systems to conform are doomed to
failure; the spec is rather unambiguous, in that 1) it refers to a particular
instant of time that cannot move, and 2) it specifically says that leap seconds
are not counted.  The only possible interpretation of this that I can see is
that, if a total of 569,022,442 seconds have elapsed since the Epoch (which was
true at one particular instant a few days ago), as defined by some standard
outside of POSIX (e.g., a counter driven by a cesium-beam clock and set to zero
at that instant by the BIH or whoever standardizes these things), "time()" must
return 569,022,428, as it is not supposed to count leap seconds.

Ultimately, the leap seconds problem can be finessed if the POSIX spec is also
fixed so as not to mandate that systems *do* sync up with e.g. WWV; the
wording in the POSIX spec would render my system non-conforming, since 1) my
machine's clock drifts and 2) I don't call WWV every morning to set the time,
nor do I have it attached to a WWV clock.  Were the standard to permit a system
to make a reasonable effort to sync up with UTC, but allow it to be off by a
couple of seconds or so (or perhaps even a couple of minutes), a system that
doesn't take leap seconds into account would have a "ctime" that gave times
that were off by a couple of seconds, but that wouldn't cause it not to
conform.  If the user cares about this, they can buy a system that has a
"ctime" that undestands leap seconds (and also sync it up with a WWV radio or
somesuch); if they don't care about this, they're not obliged to buy such a
system.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com