Re: PDT timezone bug in GNU coreutils "date" v6.9

[Philip Rowlands]

On Thu, 17 Jan 2008, Bob Proulx wrote:

> Let me state this in a slightly different way.  You are trying to use 
> GNU date's --date=STRING date parsing extension to parse the 
> historical default date format.  But the problem is that the 
> historical default date format is not exact and has the problems 
> mentioned by Paul and Phil.

I'm not quite following, sorry. Absolutely agree that strings like "EST" 
are present as the %Z "time zone abbreviation" in multiple timezones, 
and that robust software should use numerical offsets.

However, in the context of getdate's grammar, "EST" unambiguously means 
-0500, no? It's not particularly helpful to think about strings like 
"2007-07-01 EST", but it's not ambiguous to getdate. Currently, it 
seems to be invalid if the current TZ has a matching string.

If "2007-07-01 EST" is an invalid string, then a future improved date 
would need to learn the TZ mappings (EST -> US/Eastern) in order to 
consistently reject it?

I don't see the danger in allowing all possible values from 
time_zone_table for all dates, whatever the current TZ, but I suspect 
I'm missing something...


Cheers,
Phil