bug#9614: date ignoring wrong TZ values

[Sandro Santilli]

On Tue, Sep 27, 2011 at 07:19:12PM +0100, 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.?

Better than nothing, I guess.

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html