[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New time zones
Carl E . Lindberg
Re: New time zones
Mon, 21 May 2001 17:21:03 -0400
> I've looked into `tar' sources, where GNATS' getdate.y apparently
Actually I think the original ancestor is parsedate.y in the INN
package, but whatever. I'm sure GNU has had their own development fork
for a long time now.
> I think we should give up on adding new time zones and update
> getdate.y to a newer version instead. getdate.y seems to be shared >
by more GNU programs (similarly as e.g. regexp.c) and I can't see
> any reason to divert from it.
Probably a good idea. As a side note, the code that does parsing of
the military time zones should be removed (not sure if tar's version
still has it or not). getdate.y implements them per RFC822, but the RFC
got all the offsets backwards, so it's not much use. The military zones
were deprecated in a later mail RFC, and the code can actually lead to
accepting some very weird strings as valid dates.
> I also plan to replace %Z occurrences in strftime calls by %z.
> This has already been applied in the Debian GNATS package long time
> ago and there were no problems reported about it.
GNATS absolutely should switch to using numeric time zone offsets.
Trying to read the time zone abbreviations is not really feasible (as
the tar source indicated). The abbreviations were officially eliminated
in the recent mail RFC 2822, I think, because of their inherent
problems. [They had been deprecated even earlier.]
There have been fairly constant bug reports over the past few years
from people in certain locales not being able to use GNATS until they
modified getdate.y and recompiled, and switching to numeric offsets is
really the only way to solve that. getdate.y parses the numeric offsets
just fine, so there should be no problems there.
> Any objections?
Unfortunately, %z is a non-standard strftime() format. Linux has
it, which is why Debian could get away with their change. My Solaris
2.5 box supports it too, though it's undocumented. NEXTSTEP, MacOS X,
and FreeBSD 3.x don't have it, so I'd guess most/all of the BSD Unices
don't have it. Thus, making this change would unfortunately break GNATS
on a lot of platforms.
I'm not sure what the best way to fix this is.
One solution would be to always use UTC/GMT everywhere, but this is
really annoying when reading PRs (since you have to mentally convert
back to local time if the time is important).
Another would be to use GMT and have local time in parentheses,
which is effectively a comment as far as getdate.y is concerned.
Or, the code could be changed to use a custom gnats_strftime()
function, which could replace the %z itself then call strftime() to do
the rest. [Or similarly, just have a getcurrenttimestring() function to
create a time string using a consistent format.]
The last option is probably preferable, but the most work. It is
somewhat problematic if shell scripts need to create a date string --
they can't use the 'date' command anymore. At least one of the scripts
in gnats 3.x did, but I'm not sure about gnats 4. If it's still needed,
the only way around this would be to use the -u option of 'date' to
force GMT, which would always be parsed correctly at least. Or, create
a special gnatsdate program and put it in xxx/libexec, and scripts could
I have code (portable I think) that generates the numeric offset
string if anyone is interested in that.