Mail Archives: djgpp/1994/08/26/17:53:51
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 -