On 1/3/2017 2:33 PM, Tony Finch wrote: > Joe Touch <touch@xxxxxxx> wrote: > > On 1/3/2017 12:34 PM, Tony Finch wrote: > > > > > > Well, the problem is that "seconds since the epoch" is not a count of > > > UTC seconds, > > > > Correct; it's UTC-(leap seconds since epoch start). > > > > > it is a mapping from broken-down time to a linear time, > > > > Seconds since epoch is as linear as it gets. > > Except that that the number of leap seconds isn't constant, so it is > only superficially linear: there is a wrinkle at every leap second. Leap seconds are still seconds, which are counted in "seconds since epoch". > > The conversion of epoch seconds to larger units is where the leap > > seconds is counted. > > > > A "day" as a unit of time is not exactly 86400 seconds (if it were, we > > wouldn't need leap seconds). > > POSIX disagrees with you (and it is in denial about its agreement with > UTC). > > > > > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16 > > :: tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 > > There's no allowance for the number of leaps since the epoch in that > specification. Denial is not just a river in Egypt ;-) > > Try the following (and sorry about the perl, but the date command > isn't portable enough). Note that the difference between the POSIX > time_t seconds since the epoch is 1s (...8800 - ...8799 == 1) but the > elapsed time was 2s. > > $ perl -MPOSIX -e 'print strftime "%F %T\n", gmtime 1483228799' > 2016-12-31 23:59:59 > $ perl -MPOSIX -e 'print strftime "%F %T\n", gmtime 1483228800' > 2017-01-01 00:00:00 > > There is no distinct time_t value for 2015-12-31 23:59:60. In would presume that the same code would generate a time that is one second behind UTC right now. I.e., the Posix code is incorrect in claiming it reports UTC. > > To make this message slightly more on-topic for this list, anyone who > cares about this subject should be aware that NTP timestamps work > exactly the same way as POSIX timestamps, except for a constant offset > between NTP time and POSIX time due to the different choice of epoch. > The relevant difference is that POSIX does not specify how leap > seconds are handled, whereas NTP has a couple of extra bits which > allow the next leap second to be transferred (in theory but often not > in practice). NTP also has no distinct timestamp value for the leap > second, except if you include the leap indicator bits. NTP reports seconds since epoch; it is in the conversion of that value to display time that the issue of leap seconds comes into play. In that case, some systems report 59-59-00 and others 59-00-00, i.e, repeating a UTC value to account for the leap second in the human-readble output. Internally, the number of seconds which have passed is correct and include the leap second. Joe