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.
