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

[Bob Proulx]

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 documented error or opinion? Can you cite the 
> docs which explain why "Tue Jan 14 08:25:26 EDT 2008" is not valid?

  1. The timezone should be EST not EDT.
  2. January 14, 2008 is a Monday not a Tuesday.

> I can't find any (otherwise I'd stop arguing :)), which is why I ask 
> whether treating "EDT" as "-0400" is technically wrong or aesthetically 
> wrong. getdate isn't confused, and with a non-conflicting TZ will handle 
> the input unambiguously.

The parsing of dates with 'date --date=STRING' is a GNU extension and
not covered by any standards beyond those to which GNU holds itself.
In which case whatever GNU decides to do is what it decides to do.

I was basing my answer upon general mailing list discussion which
shows that error handling is being tightened up in general.  (Uncaught
errors are often the source of silent data corruption.  Therefore
errors should be caught and handled at the earliest appropriate
place.)  Date should catch invalid dates so that they can be handled.
Past mailing list discussion has indicated that date should be strict
about parsing of dates.  I don't have any other authoritative
reference.

Having said all of that the question remains as to whether "Tue Jan 14
08:25:26 EDT 2008" should be considered an invalid date or not.  There
is no location upon which anyone would ever have received that
timestamp.  It cannot have occurred naturally.  There are two problems
with it.  One is that at the date EST was in effect.  Second is that
Jan 14 2008 is a Monday not a Tuesday.  So shouldn't that be flagged
as being invalid?  I think it should.

What should be done when the timezone is ambiguous?  What should be
done when the timezone is invalid?  There have been a number of
complaints about date falling back to interpreting timezones as UTC
without flagging an error.  It is a little hard to tightly code use of
date if it is not possible to determine if a timezone error occurred
inadvertently.  But for text string timezones it would be a possible
direction for GNU date to take that best guesses will be applied and
no errors will be reported.  I vote against this however.

What do you think?

Bob