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

[Dave Daugherty]

Adding Zihao from Centrify

Tom, we plan to address this issue in our next round of development fixes - my guess is in the next couple of months.

It will probably be Zihao's team implementing/testing the fix.

As I said we will test this on many different platforms and versions - AIX, HPUX, Solaris, OS/X and many forms of Linux.

Do you have a fix already that you would like us to test, or would you like us to take a run at it?

Dave Daugherty

Centrify

> -----Original Message-----
> From: Tom Yu [mailto:tlyu at MIT.EDU]
> Sent: Thursday, July 07, 2011 7:16 PM
> 
> 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.