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 _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils