[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New time zones

From: Carl E . Lindberg
Subject: Re: New time zones
Date: Mon, 21 May 2001 17:21:03 -0400

> I've looked into `tar' sources, where GNATS' getdate.y apparently
> originates.

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 use that.

I have code (portable I think) that generates the numeric offset string if anyone is interested in that.

        -Carl Lindberg

reply via email to

[Prev in Thread] Current Thread [Next in Thread]