Date:	Fri, 26 Aug 94 12:01:35 CDT
From:	"Cave Newt" <roe2 AT midway DOT uchicago DOT edu>
To:	djgpp AT sun DOT soe DOT clarkson DOT edu, storner AT olicom DOT dk
Subject:	Re: Why TZ=EST5EDT fails
Cc:	dj AT ctron DOT com

With luck all of this will be irrelevant when DJ finishes his fixes,
but it sounds like they may depend on the end-user having 300K of
timezone files lying around, which probably isn't going to happen.
So just in case...

> tzparse() - which parses the TZ specification - does all the right things,
> computing correct values for the standard offset and DST offset. It then
> sees that tzload() failed, and aborts in line 773. Net result: All time
> functions use localtime, as if TZ=GMT0.

This may be technically correct, but I would argue that it's wrong in
"spirit."  It should make the best approximation it can in the absence
of the timezone files--at a minimum, parse "PST8PDT" as plain "PST8".
(Even better would be to guess at the appropriate dates for DST, but
that's not absolutely necessary.)

> I guess there isn't much that can be done about this. Distributing
> zoneinfo files with DJGPP seems a bit much; picking a default rule to
> apply when none is specified in the TZ setting is bound to fail on
> some systems - the very reason for the zoneinfo files being that DST
> changes are not universally coordinated.

I don't understand the second comment.  How do you get from TZ=EST5EDT
to "none is specified in the TZ setting"?  Picking the default rule to
be the same as if TZ=EST5 is much better than the current default of
pretending it's GMT0; and guessing at the dates for DST is better still
--you're off by an hour for at most a few days per year instead of for 
six months per year (or, as is currently the case, off by many hours for 
the whole year :-) ).

Greg

- Raw text -