bug#14229: invalid TZ and /bin/date

[Donald Berry]

Yes, date/GNU accepts whatever TZ string you pass it without error, but this 
leads to very confusing results.  Here again is one of the examples:

[dberry <at> dberry ~]$ TZ=foo date -d @0
Thu Jan  1 00:00:00 foo 1970

I think it is safe to say that 'foo' is not a valid timezone, and yet date 
returns the UTC result, but displays it as timezone foo.

Even more confusing is using a string that the user may think is valid, such as 
EDT.  Again date returns the UTC result, but displays it as timezone EDT.

[dberry <at> dberry ~]$ TZ=EDT date -d @0
Thu Jan  1 00:00:00 EDT 1970

It seems that when date does not understand the string it returns the UTC 
result, but echoes the string back as the apparent timezone, or at least 
attempts to - date has a limit on the number of characters it supports:

address@hidden ~]$ TZ=America/Eastern date -d @0 # invalid TZ string
Thu Jan  1 00:00:00 America 1970

There are other strings that date does understand, and in fact translates them 
into another timezone in the output, e.g.:

address@hidden ~]$ TZ=America/Phoenix date -d @0
Wed Dec 31 17:00:00 MST 1969

Is there any documentation of what the supported/recognized TZ strings are?  
Are there any plans to reject invalid strings?  I did see there was a similar 
bug reported in 2011 (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9614).  

Don

----- Original Message -----
From: "Paul Eggert" <address@hidden>
To: "Donald Berry" <address@hidden>
Cc: address@hidden
Sent: Thursday, April 18, 2013 5:29:33 PM
Subject: Re: bug#14229: invalid TZ and /bin/date

On 04/18/13 13:24, Donald Berry wrote:
> If an invalid TZ argument is passed to /bin/date,
> it silently fails but prints the UTC result

In the GNU system there is no such thing
as an invalid TZ string.  Every TZ string has
some interpretation (typically as UTC).
This is true not just for /bin/date, but for
every other program.