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

[Bob Proulx]

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
everything in a message.  But if we said them all the messages would
always be so long that no one would read them.  So I didn't say
everything that popped into my head.  (Thank goodness!)  But this
message suffers from being fairly long because of it.

> However, in the context of getdate's grammar, "EST" unambiguously means 
> -0500, no? It's not particularly helpful to think about strings like 
> "2007-07-01 EST", but it's not ambiguous to getdate. Currently, it 
> seems to be invalid if the current TZ has a matching string.

But the case under discussion was PDT not EST.

  $ TZ=US/Pacific date -d"Tue 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 (you saw my
comment about UTC since that would not be ambiguous so I am not biased
against string timezones per se) but when things like this fail I
think it is best to avoid them regardless.  Even date's string
timezone can be improved I think it is still better to use numeric
timezone offsets.  Since the problem is centered upon use of the
default 'date' output I directed my comments toward highlighting that
'date -R' exists and can easily avoid the issue entirely.  This was
probably off in the weeds because the underlying problem was that the
date presented was an invalid date.

  $ zdump -v US/Pacific | grep 2008
  US/Pacific  Sun Mar  9 09:59:59 2008 UTC = Sun Mar  9 01:59:59 2008 PST 
isdst=0 gmtoff=-28800
  US/Pacific  Sun Mar  9 10:00:00 2008 UTC = Sun Mar  9 03:00:00 2008 PDT 
isdst=1 gmtoff=-25200
  US/Pacific  Sun Nov  2 08:59:59 2008 UTC = Sun Nov  2 01:59:59 2008 PDT 
isdst=1 gmtoff=-25200
  US/Pacific  Sun Nov  2 09:00:00 2008 UTC = Sun Nov  2 01:00:00 2008 PST 
isdst=0 gmtoff=-28800

This shows that on my system PDT begins on Mar 9 10:00:00 2008 UTC and
therefore "Tue Jan 14 08:25:26 PDT 2008" cannot be a valid time in the
US.  It may be a valid time elsewhere.  (I should have asked how such
a date string was generated in the first place given that it is an
invalid string.)  At that moment the timezone should be PST instead if
that is in the US/Pacific timezone.

> If "2007-07-01 EST" is an invalid string, then a future improved date 
> would need to learn the TZ mappings (EST -> US/Eastern) in order to 
> consistently reject it?

I think the case here is that timezone strings are bound by the
legislated geography of the area.  Use of Daylight Saving Time is a
local convention.  The actual time can only be determined by
consulting data tables to map local time into UTC.  If the mapping
fails because the indicated time does not exist then it should return
the an appropriate error.

Using numeric timezones bypasses the local DST convention check by
moving outside of region specific geographically legislated timezones
entirely.  In this case it doesn't really address the issue.  It
simply bypasses it.  Many times in practice we don't really care
whether local convention uses DST or not.  Using UTC or using number
timezones simply avoids the issue.

I am in US/Mountain (-0700) right now and of course in the summer when
DST is in effect that is -0600.  If I use MST or MDT that means
consult the tables to find the actual offset.  But if I use -0700 no
table lookup is used and that conversion must work even if I use -0700
when DST is in effect or -0600 when it is not.  The result of a
numeric timezone error simply makes it look as if I were
geographically located in a different location than I really was
located but the string can still be parsed without error.

But what was especially confusing was that EDT worked with
TZ=US/Pacific!  This is a bug in 'date'.

  $ TZ=US/Mountain date -d"Tue Jan 14 08:25:26 EDT 2008"
  Mon Jan 14 05:25:26 MST 2008

But:

  $ TZ=US/Eastern date -d"Tue Jan 14 08:25:26 EDT 2008"
  date: invalid date `Tue Jan 14 08:25:26 EDT 2008'

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.  The invalid date string is only detected when
parsed within the context of the same timezone.  That is a bug.  This
is where Paul answered:

> Paul Eggert 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 reject the time stamp now.  Fixing this bug
> > would take some time and is low priority.  In the mean time, though,
> > portable code shouldn't rely on invalid time stamps.

So eventually we might see date enhanced to detect invalid timestrings
regardless of the local timezone setting.

> I don't see the danger in allowing all possible values from 
> time_zone_table for all dates, whatever the current TZ, but I suspect 
> I'm missing something...

I may be missing something as well.  And I apologize for taking a
roundabout approach to answering in this reply.

To gmane I should ask how such an invalid date string was created in
the first place?

Bob

P.S. One day I plan on spending all of that saved up daylight that I
get from daylight saving time. :-)