--- 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.
+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 are a bit out of scope for a time zone database,