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

[Tom Yu]

Andrew Bartlett <abartlet at samba.org> writes:

> Well, it wasn't an installer issue, at the time, I reproduced it locally
> by setting a Seattle time-zone.  Perhaps there was a bug in the Fedora
> tz db at that particular moment, or some other quirk.

What method did you use for setting the time zone?  Was it by direct
manipulation of /etc/localtime (or similar), or by running some Fedora
utility program?

> I'm still incredibly wary of having any behaviour that breaks things so
> subtly depending on a timezone setting.

I understand.  My proposal is no more broken than the existing
behavior if the system lacks a native timegm().  I consider my
proposal to be an acceptable intermediate state, given the (as yet)
lack of evidence of systems that provide "right" time zone files but
that lack timegm().

(I also consider it a bug for any OS to make it easy for someone to
configure a "right" time zone without explicit acknowledgment of the
risks of doing so.)

> If you must try and use the system function (meaning that the internal
> implementation is almost never tested) always use a matching pair of
> either internal or system timegm() and gmtime() functions.

I agree that it would be ideal to always have matching timegm() /
gmtime() pairs, whether native or substituted.  At this point I am
considering implementing a gmtime() substitute that ignores leap
seconds (when the system lacks a native timegm()) to be a low-priority
enhancement request, because, among other things, the formatted time
it emits will be wrong (ironically enough) if the system is configured
for a "right" time zone.

If someone can provide evidence of a system that provides "right" time
zone files yet fails to provide timegm(), I will be happy to raise the
priority on making that improvement.  Perhaps we should ask the time
zone mailing list for more information, but I don't know how closely
they track the uptake that individual OSes have of particular Olson
tzcode changes.