Re: New time zones

Re: New time zones

[Milan Zamazal]

>>>>> "YS" == Yngve Svendsen <yngve.svendsen@clustra.com> writes:

    YS> Going through the Gnats reports, I noticed a couple more missing
    YS> time zones.

I've looked into `tar' sources, where GNATS' getdate.y apparently
originates.  The commentary before the time zone table there says:

/* The time zone table.  This table is necessarily incomplete, as time
   zone abbreviations are ambiguous; e.g. Australians interpret "EST"
   as Eastern time in Australia, not as US Eastern Standard Time.
   You cannot rely on getdate to handle arbitrary time zone
   abbreviations; use numeric abbreviations like `-0500' instead.  */

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.

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.

Any objections?

Milan Zamazal

-- 
Here is my advice, don't try to program the bleeding edge for the
general populace unless you really, really, really like migraines.
						   Neal H. Walfield

Re: New time zones

[Yngve Svendsen]

At 20:38 01.05.2001 +0200, Milan Zamazal wrote:
>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.
>
>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.
>
>Any objections?

None whatsoever. Using a "standard" getdate.y is a good idea.

- Yngve

Re: New time zones

[Carl E. Lindberg]

 > 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