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

[Dave Daugherty]

Okay - really adding Zihao...


> -----Original Message-----
> From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf
> Of Dave Daugherty
> Sent: Monday, July 11, 2011 11:59 AM
> 
> 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.
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev