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

[Bob Proulx]

Paul Eggert wrote:
> <address@hidden> 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 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

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.

On quick glance it might seem that using 'date' output should work
because it is the default, right?  But it doesn't because of the
ambiguous nature of it.  It is the default because of legacy.  That is
the original US centric format before people became concerned about
international use.  It wasn't a problem then but it is a problem now.

Better is to use the 'date -R' format which is not ambiguous.  Then
the GNU date --date=STRING extension won't have problems parsing it.
I think if you retrain yourself to type in 'date -R' everywhere that
you should have used 'date' previously it will make things simpler and
unambiguous.  I almost never use a plain 'date' anymore.

  $ date -R
  Thu, 17 Jan 2008 16:00:39 -0700

  $ 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

Paul, can "UTC" be counted upon to be unambiguous in that location?

Hope that helps,
Bob