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

[Paul Eggert]

<address@hidden> 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 epoch (or julian for that 
> matter) is to allow for easy machine comparison and sorting of 
> date/time stamps.  In such case, if the data contains date/time 
> stamps from multiple timezones, one must be able to convert to 
> epoch relative to one's local timezone otherwise proper sorting can 
> not be achieved.

Sure, but if the data contains _alphabetic_ time zone abbreviations
from multiple sources, then the user is in trouble.  There is no
standard for alphabetic time zone abbreviations.  "EST" means one
thing in the U.S. and a different thing in (actually, _two_ different
things) in Australia.  "date" cannot reasonably be expected to support
alphabetic time zone abbreviations in general.  If they work, great;
but there are no guarantees.

> I can assure you that 
> this error occurs regardless of the time stamp format 
> used/provided.

No, it works just fine with numeric time stamps, where there is no
ambiguity.  For example:

$ date -d "Tue Jan 14 08:25:26 PDT 2008" +%s
date: invalid date `Tue Jan 14 08:25:26 PDT 2008'
$ date -d "Tue Jan 14 08:25:26 -0700 2008" +%s
1200324326
$ echo $TZ
America/Los_Angeles