On 1/3/2017 3:14 PM, Tony Finch wrote:
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.
A leap second is just a way to stall the UTC representation so it takes
61 seconds for a particular minute to pass, but the seconds still pass
and the seconds since epoch ought to increment accordingly.
The Posic spec describes how to convert seconds since epoch to UTC; it
is that conversion where leap seconds come into play.
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,
If 1483228799 is the correct number of TAI seconds since the Unix epoch
and if that accurately represents 2016-12-31 23:59:59, then 2017-01-01
00:00:00 should not have been output until 1483228801.
Since that wasn't accounted for, we are displaying a "Posix UTC" time
that is one second ahead of where UTC actually is.
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 ?
UTC defines it that way, so if you want to output the correct UTC value,
that is the only solution.
Any other solution - smear, repeating times (59-59-00 or 59-00-00) can
be generated, but would be incorrect relative to UTC.
Joe