Re: Simplifying timezone support

According to my sent folder, this went out Monday afternoon, but I
haven't seen it yet, so I'm resending to the list only, without the
attached patch. I'll send the patch over to patches.

Any comment on the behavior, specifically, the heuristic for deciding
tzset() failed, and the proposed order of application of tzset()
vs. table lookup?

Ross

On Mon, Feb 24, 2003 at 03:34:56PM -0600, Ross J. Reedstrom wrote:
> On Fri, Feb 21, 2003 at 08:39:12PM -0600, Ross J. Reedstrom wrote:
> >
> > Every other validly formatted TZ variable that returns GMT should be
> > caught be the datetktbl check.
> >
> > I'll play with it this weekend, see how hard it is to make it work.
>
> O.K., the weekend's over, And I've created two different version
> of this. Both work, ipass all the regression test, and solve the
> 'CST is just a funny way to say GMT' problem. I was able to make use
> of DecodePosixTimezone (DPT) from Thomas's datetime parsing code in
> assign_timezone. However, the order of application of this vis. tzset
> is unclear.
>
> I had proposed doing the DPT first, then tzset, then a NOTICE if it
> looked like tzset didn't. Got that working, but discovered a change of
> behavior: for some of those who have a timezone in the zoneinfo database
> that is a three letter abbreviation, the current code (tzset only) will
> provide daylight savings time transitions, so that a timestamp in July
> returns a different timezone than one in February. This is not true for
> our internal values of set time zone: there, we convert to a numerical
> offset, which is constant no matter when the timestamp occurs.
>
> This is still a win for those who's timezone abbreviation is _not_ in the
> zoneinfo DB, (such as CST), which currently is silently interpreted as
> an odd spelling of GMT.
>
> Second solution - try tzset() first, and apply the following heuristic
> to see if it took:
>
> tzname[0]==$TZ and tzname[1]=="" and timezone=0 and daylight=0
>
> In other words, _all_ the timezone related information remains the
> default. I tested this against the 1607 zoneinfo files on my system:
> every one was filtered out, even things that _are_ GMT with no DST (they
> all had a non-null tzname[1] == tzname[0])
>
> If this succeeds (i.e. tzset didn't recognize the TZ), go ahead and look
> it up in our big table'o date/time strings. This also works, fixing the
> bogus GMT spellings, without changing current behavior for any string
> that is not bogus.
>
> Note that the sysadmin can always tell if tzset or the table was used, by
> looking at the format of the 'show time zone' result. If tzset was called,
> this is the string that was passed to 'set time zone'. If the table was
> used, it will be an hours west of GMT offset.
>
> The problem with this approach is that it does nothing to reduce our
> dependency on the OS timezone functionality.
>
> Comments? I've attached the second patch for discussion.
>
> Ross
>