prevalence of "right" time zones without timegm()?

[Tom Yu]

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.

Background information:

  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.