Joe Touch <touch(_at_)isi(_dot_)edu> wrote:
Leap seconds are still seconds, which are counted in "seconds since
epoch".
Can you you show me where in the POSIX spec linked below leap seconds
are counted? I thought they were not.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16
$ 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
In would presume that the same code would generate a time that is one
second behind UTC right now.
I'm not sure what you mean. If you add (24+24+23)*3600 seconds to
1483228800 you get 23:00:00 today, which is the same length of time
after 2017-01-01 00:00:00. Nothing is one second behind now. Except it
has taken me more than 600 seconds to write this message.
I.e., the Posix code is incorrect in claiming it reports UTC.
Yes, I agree.
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.
But if the count of seconds includes the leap second, surely the number
representing the leap second could be printed properly as :60 ?
Tony.
--
f.anthony.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/ - I xn--
zr8h punycode