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 _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
