[17021] in Kerberos_V5_Development
RE: prevalence of "right" time zones without timegm()?
daemon@ATHENA.MIT.EDU (Dave Daugherty)
Mon Jul 11 14:58:56 2011
From: Dave Daugherty <dave.daugherty@centrify.com>
To: Tom Yu <tlyu@mit.edu>, Andrew Bartlett <abartlet@samba.org>
Date: Mon, 11 Jul 2011 11:58:48 -0700
Message-ID: <6E90015C52F4FA478E0E30CD3BC6479837D5E262C5@exch-07.centrify.com>
In-Reply-To: <ldvbox5jz5e.fsf@cathode-dark-space.mit.edu>
Content-Language: en-US
MIME-Version: 1.0
Cc: "tridge@samba.org" <tridge@samba.org>, "lha@samba.org" <lha@samba.org>,
"krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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@MIT.EDU]
> Sent: Thursday, July 07, 2011 7:16 PM
>
> Andrew Bartlett <abartlet@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@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
