FW: gnats devel FW: New time zones

[Dirk Bergstrom]

i passed the last message on to a guy in my group who has a lot of clue
about timezone processing.  his reply is below.

--
Dirk Bergstrom               address@hidden
_____________________________________________
Juniper Networks Inc.,   Engineering Web Guru
Tel: 408.745.3182           Fax: 408.745.8095
 

-----Original Message-----
From: Mark Baushke 
Sent: Monday, May 21, 2001 2:51 PM
To: Dirk Bergstrom
Subject: Re: gnats devel FW: New time zones 

Using time always in UTC (aka GMT) with a parenthetical comment of the
local time (using a numeric offset) would be best.

RFC 822 has been superceeded by RFC 2822.

As has been noted, %z is a non-standard format for strftime().

I typically build-my-own %z equivalent out of using the same reference
time and passing it to both localtime() and gmtime() converting back
to seconds and then doing the subtraction to get the offset in seconds
and dividing by 36 to get 'hours' in hundreds.

Carl E. Lindberg [mailto:address@hidden writes:
>     I have code (portable I think) that generates the numeric offset 
>string if anyone is interested in that.

I suggest someone take Carl up on his offer.

For what it is worth, the %z format was introduced to FreeBSD 4.0 in
that lib/libc/stdtime/strftime.c in version 1.25 of the file which was
in FreeBSD 4.0 and subsequent releases contains the patch to support it.

My recommendation would be to use a configure test for the %z format
and then use strftime() if it works or use a compatibility package if
it does not.

        -- Mark

> -----Original Message-----
> From: Carl E. Lindberg [mailto:address@hidden
> Sent: Monday, May 21, 2001 2:21 PM
> To: Milan Zamazal
> Cc: address@hidden
> Subject: Re: New time zones
> 
> 
> 
>  > 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