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 territory of
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 meaning
On Thu, 17 Jan 2008, Bob Proulx wrote:
But the case under discussion was PDT not EST.
$ TZ=US/Pacific date -dTue 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
[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 converting to
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 me... Since
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.
No, it works
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
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 about
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 correctly
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 time (vs
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 -dTue Jan 14
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 that
13 matches
Mail list logo
