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

[Tom Yu]

Andrew Bartlett <abartlet at samba.org> writes:

> This does really happen in the real world, and is a nightmare to track
> down (I spent hours on it).  We (Samba Team) found it out via Heimdal,
> and Fedora 13 or 14 (current as of 2010-09) systems in Seattle time zone
> (while at a Microsoft interop :-)

What are the business reasons for configuring a "right" time zone?
And do the people who choose to do so fully recognize the risks
involved?

> The eventual solution was that Heimdal implements both directions of the
> gmtime() and timegm() manually, without regard to the leap second
> database.  From our experience I strongly recommend MIT chooses to do
> the same. 

After having thought some more about the way Heimdal works around this
problem, I realized that on a system with a "right" zone configured,
the encoded GeneralizedTime won't be the correct value of UTC.  (The
time_t values on that system will incorporate leap seconds, and the
manually coded gmtime() won't correct for them.)  It might not matter
much now with 24 total leap seconds, but could cause problems when
more leap seconds accumulate in the future, especially if we decrease
the allowable clock skew.

I think using a native timegm() where available is a cleaner solution.
If there is a strong case for dealing with leap-second-related UTC
encoding/decoding asymmetry on systems that lack a native timegm(),
I'll consider more complex solutions.