prevalence of "right" time zones without timegm()?
tlyu at MIT.EDU
Tue Jul 5 15:18:59 EDT 2011
Does anyone configure a "right" (leap-second-aware) time zone on a
system that lacks timegm()? (timegm() is the non-standard inverse
function of gmtime().) I'm trying to address the problem where
conversion to formatted ASN.1 GeneralizedTime is sometimes
non-invertible, causing failures that are difficult to debug.
I propose that we implement krb5int_gmt_mktime() using timegm() on
systems that have it, using our existing custom implementation if
timegm() doesn't exist. This will improve the behavior of our code in
a "right" time zone on a system with timegm(), but will preserve the
existing broken behavior when parsing a formatted GeneralizedTime into
a time_t value on a system that lacks timegm() and is configured with
a "right" time zone.
My hypothesis is that it is very rare that a system is configured with
a "right" time zone and also lacks timegm(). If you have evidence
about this hypothesis, please let me know.
There are possible alternative solutions to this problem that also
work on systems that lack timegm(), but they are more complicated or
have other drawbacks. To keep discussion focused, I prefer not to
describe them in detail unless there is a strong opinion that my
proposal is not viable.
The Olson time zone database can be compiled to include support for
leap seconds. Some operating systems do so, producing an
alternative set of zone files known as the "right" zone files. I
believe that most OSes do not configure a "right" time zone by
default. (I would not recommend using the "right" zone files on
anything other than a completely isolated system.)
In order for a system configured with a "right" zone to produce
correctly formatted times, the time_t values returned by the time()
function on that system need to include a count of all the leap
seconds that have occurred (24 seconds as of 2009), contrary to
POSIX, which effectively requires that every minute have exactly 60
seconds. Obviously, this will cause many problems when exchanging
time data with POSIX-conforming systems, but one particular problem
affects the krb5 code.
Our library uses gmtime() to format time_t values for encoding into
GeneralizedTime in ASN.1 messages. An internal function,
krb5int_gmt_mktime(), converts formatted times into time_t values.
On a system where a "right" time zone is configured, these
conversions will not be inverses, because gmtime() will incorporate
accumulated leap seconds, and krb5int_gmt_mktime() will not. This
results in mismatches in the small number of places where our
library makes exact time comparisons.
More information about the krbdev