[Top][All Lists]

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

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

From: Philip Rowlands
Subject: Re: PDT timezone bug in GNU coreutils "date" v6.9
Date: Fri, 18 Jan 2008 02:37:50 +0000 (GMT)

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


reply via email to

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