On 02/09/16 17:53, Steve Allen wrote:
On Fri 2016-09-02T09:41:31 -0700, Paul Eggert hath writ:
whereas I was asking about end-user applications that need months-in-advance notice of leap seconds. As Bradley writes, most of the world that cares about leap seconds uses NTP and does not depend on tz-derived leap seconds information.
I think anything which handles a leap second is a hack which is violating a standard from one agency or another, the implementors are not wont to describe that or how they are violating a standard, there is inconsistency between implementations, and no generalization applies to how the information is being used.
Standards. Wonderful things, that is, things full of wonder. Or something. Posix mandates that there are 86400 seconds in a day while still allowing struct tm to have its tm_sec field in [0,61). The rationale for this seems to be that programmers expect sleep(60) to sleep for a minute (notwithstanding some implementations waking early). It wriggles out of the dichotomy by saying that the epoch that time(2) returns seconds since is only approximately 1970-01-01 and doesn't require gmtime(3) et al to ever return a value with tm_sec == 60. Indeed, given that there are exactly 86400s in a day it's not possible to feed an integer to gmtime(3) et al to get 23:59:60. As you say, though, Steve, different platforms have different non-standard ways of dealing with this. Linux and *BSD's ntp_gettime will return a specific value if you are in a leap second so a wily implementation of gmtime_now() can use that to actually return 23:59:60 when it happens and anyone who wants to store that as a timestamp had better not try to convert it to seconds-since-the-epoch :) jch