On Jan 28, 2008 1:23 AM, Bob Proulx <[EMAIL PROTECTED]> wrote:
> What should be done when the timezone is ambiguous?
That's a tiny minority of cases, and a case which many people will not
think to check. Therefore I think the most helpful thing a tool can
do is fail with an explanatory message.
Philip Rowlands wrote:
> Bob Proulx wrote:
> >Consulting the tables with 'zdump -v US/Eastern | grep 2008' shows
> >that indeed "Tue Jan 14 08:25:26 EDT 2008" is not a valid date in that
> >timezone. It should be flagged with an error regardless of local
> >timezone setting.
>
> Are we in the
Philip Rowlands <[EMAIL PROTECTED]> writes:
> However, in the context of getdate's grammar, "EST" unambiguously
> means -0500, no?
No. Not necessarily. It depends on your TZ setting. It might
reasonably mean +1000, for example. One cannot rely on "EST" meaning
-0500. Nor can one rely on "PDT
On Thu, 17 Jan 2008, Bob Proulx wrote:
But the case under discussion was PDT not EST.
$ TZ=US/Pacific date -d"Tue Jan 14 08:25:26 PDT 2008"
date: invalid date `Tue Jan 14 08:25:26 PDT 2008'
At this point I don't know if PDT is ambiguous or not
Not to getdate. There is one "PDT" entry in ti
Philip Rowlands wrote:
> 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.
Agreed.
There are always ten zillion things that one wants to say ab
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 problem
Bob Proulx wrote:
> $ date -d "$(date -R)" +%s
> 1200610873
>
> Unfortunately use of -R is not portable. POSIX defines -u however.
> That might work better for you in your task anyway.
>
> $ date -u
> Thu Jan 17 23:03:27 UTC 2008
>
> $ date -d "$(date -u)" +%s
> 1200611075
Oh silly
Paul Eggert wrote:
> <[EMAIL PROTECTED]> writes:
> > ... or that the date/time format provided to the "-d" option in
> > this particular example is an invalid time stamp?
>
> A bit of both.
>
> ...
> > I can assure you that this error occurs regardless of the time
> > stamp format used/provided.
>
<[EMAIL PROTECTED]> writes:
> Did you mean to say that converting any given time to epoch is
> invalid for time stamp purposes, or that the date/time format
> provided to the "-d" option in this particular example is an
> invalid time stamp?
A bit of both.
> Typically the reason for convertin
On Tue, 15 Jan 2008 22:06:38 -0800 Paul Eggert <[EMAIL PROTECTED]>
wrote:
>The actual problem is the reverse of the original complaint.
>Coreutils should reject a usage like 'date -d "Tue Jan 14 08:25:26
>EDT
>2008" +%s', because that time stamp is invalid. Coreutils is not
>smart enough to co
Philip Rowlands <[EMAIL PROTECTED]> writes:
> Although the coreutils documentation cautions about using ambiguous
> timezone labels like this,
The actual problem is the reverse of the original complaint.
Coreutils should reject a usage like 'date -d "Tue Jan 14 08:25:26 EDT
2008" +%s', because th
On Tue, 15 Jan 2008, [EMAIL PROTECTED] wrote:
I believe I have identified a bug in the GNU coreutils "date" utility
when handling the PDT timezone.
I'm running Fedora 8 kernel 2.6.23.9-85.fc8, and the command "date -
-version" reports: date (GNU coreutils) 6.9
[snip]
$ date -d"Tue Jan 14
To whom it may concern:
I believe I have identified a bug in the GNU coreutils "date"
utility when handling the PDT timezone.
I'm running Fedora 8 kernel 2.6.23.9-85.fc8, and the command "date -
-version" reports: date (GNU coreutils) 6.9
When using the "-d" option to display the specified tim
13 matches
Mail list logo
