In message: <[email protected]> Chuck Harris <[email protected]> writes: : Poul-Henning Kamp wrote: : > In message <[email protected]>, 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 _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
