--- theory.html 2019-02-20 18:17:59.000000000 -0500 +++ theory.html.new 2019-08-17 08:22:19.000000000 -0400 @@ -1072,7 +1072,8 @@ where time_t is signed.
  • - These functions can account for leap seconds, thanks to Bradley White. + These functions can account for leap seconds; + see the section on "Leapsecond Support" below.
  • @@ -1249,6 +1250,56 @@
    +

    Leapsecond Support

    +

    +The tz code and data can account for leap seconds, +thanks to code contributed by Bradley White. +The mechanism assumes that the OS kernel counts all seconds since 1970, +including leap seconds. +(This is by contrast to the Posix definition, +which explicitly ignores leap seconds.) +The conversion from this modified timescale to UTC +(including the insertion or deletion of leap seconds, as necessary) +occurs at the same point that timezone and DST adjustments are applied -- +namely, at calls to localtime and analogous functions -- +and the process is driven by leapsecond information +stored in alternate versions of the time zone files. +

    +The alternate set of time zone files is referred to as the "right" zones, +because they were traditionally organized +in a separate subdirectory of that name. +In general, however, it is desirable to install just one set of +files on a given system, +either the conventional or the leapsecond-observing set. +(The choice would obviously depend on +whether the system in question is known to be counting leap seconds +and keeping the modified timescale internally.) +To build and install the "right" zones, +set the REDO variable in the Makefile +according to the instructions there. +

    +With a kernel clock counting leap seconds, +all raw timestamps returned by or sent to the kernel +will necessarily include leap seconds, +and will therefore not match Posix UTC time_t values. +To convert raw timestamps to or from Posix UTC timestamps +(for use when, say, +embedding or interpreting those raw timestamps in tar files), +you can use the utility functions +time2posix and posix2time +included with this package. +

    +Of note is that when using the "right" timezones, +the leapsecond adjustment is required +whether or not any actual timezone correction is being applied. +This means that calls to gmtime will also make use of a zonefile; +if necessary + +zone "GMT" +will be used for this purpose. +

    + +

    Calendrical issues

    Calendrical issues are a bit out of scope for a time zone database,