bug#9614: date ignoring wrong TZ values

[Pádraig Brady]

On 09/27/2011 07:19 PM, Pádraig Brady wrote:
> On 09/27/2011 03:09 PM, Sandro Santilli wrote:
>> I've been puzzled by date(1) giving weird results
>> when setting TZ to values unknown by zoneinfo.
>>
>> As far as:
>>
>>  $ TZ=Fake date
>>  Tue Sep 27 14:06:32 Fake 2011
> 
> Yes, that is per POSIX.
> One can specify info about the timezone in TZ
> like TZ="Fake+6", so one couldn't start warning about that.
> 
>> It would be more helpful if the command raised an error 
>> or warning about "unknown" timezones rather than giving
>> random dates.
>>
>> It's particularly anonying when the same TZ _reported_
>> by the command isn't recognized in input:
>>
>>   $ date
>>   Tue Sep 27 16:08:13 CEST 2011
>>
>>   $ TZ=CEST date
>>   Tue Sep 27 14:08:13 CEST 2011
>>
>> Thanks for making a clock available for everyone, btw :)
> 
> Wow you learn something everyday.
> I thought the TZ=XYZ was just treated as UTC+0
> to allow one to specify TZ=XYZ+4 etc. as
> an offset from UTC.
> 
> But in fact some TZ values are matched,
> as can be seen for CET here on my system:
> 
> $ TZ=CEST date
> Tue Sep 27 18:03:05 CEST 2011
> $ TZ=CET date
> Tue Sep 27 20:03:09 CEST 2011
> $ date
> Tue Sep 27 19:03:17 IST 2011
> 
> There are a few three letter codes on my
> system at /usr/share/zoneinfo/
> (maybe these are the only non ambiguous ones?)
> 
> Hmm, how about we warn if an unmatched code (without a /)
> is specified, without any other info like UTC offset etc.?

Actually we could warn about unmatched codes containing / too.

I just noticed more inconsistencies, for codes that are matched:

 $ TZ=NZ+1 date # No zone reported
 Tue Sep 27 21:03:06  2011
 $ TZ=CET+1 date # Zone reported
 Tue Sep 27 20:03:16 CET 2011

thanks,
Pádraig.