Re: Simplifying timezone support

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