[time-nuts] Leap Quirks

[M. Warner Losh]

In message: <495FD637.5030105 at erols.com>
            Chuck Harris <cfharris at erols.com> writes:
: Poul-Henning Kamp wrote:
: > In message <495FB615.9080200 at rubidium.dyndns.org>, Magnus Danielson writes:
: > 
: >>> Having a message from ntp.c that says there was a leap
: >>> to HH:MM:60 implies that HH:MM:60 is a valid time as far
: >>> as ntp.c's author is concerned.
: >> It is valid UTC time, not valid POSIX time, which are two different things.
: > 
: > Well, it is a valid POSIX time, but it means a second later than
: > desired in this case, because the 60 is taken as 60 seconds, and
: > folded into a minute-roll-over.
: > 
: >>> Having used unix since edition V, I am also aware of how unix
: >>> systems count off seconds since the epoch 1/1/1970.  But that
: >>> really is immaterial to the discussion.
: > 
: > No, that is actually the crux of the matter...
: 
: Ok, that is news to me.  Are you saying that (pulling a number out of
: the air) time_t = 21120123 could be followed by 21120123 on a year where
: we added a leap second?

Yes.  Leap seconds don't exist in POSIX time_t, so the pedantically
proper value is undefined.  Most implementations repeat a second
(either 59 or the 00 second) to cope with this omission.

: It is my understanding that it cannot.  I believe that time_t must
: increment by one as each second passes, and must contain the number of
: seconds that have passed since the unix epoch on 1/1/1970... without
: regard for leap seconds.

That isn't what POSIX says.  POSIX is very clear that leap seconds do
not exist, and therefore the correct answer for the first second of a
year (or of any day) always ends in '00'.

: I was of the understanding that the problem was in how the UTC time was
: calculated from time_t, and the converse.

The problem is that the conversion of time_t to a 'broken down' UTC
time isn't 1:1 or onto.

Warner