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
