ulima wrote: > environment vaiable TZ doesn't work: see: <<<<<<<<== BUG (GMT==UTC)
Thank you for the bug report. However I think you are misunderstanding the data format of the TZ variable. Please read this reference for the specification. http://www.gnu.org/s/libc/manual/html_node/TZ-Variable.html > % un uli /home/uli 1 } date > Sat Mar 13 19:26:28 CET 2010 > % un uli /home/uli 2 } setenv TZ 'America/Montevideo' > % un uli /home/uli 3 } date > Sat Mar 13 16:26:42 UYST 2010 > % un uli /home/uli 4 } setenv TZ UYST > % un uli /home/uli 5 } date > Sat Mar 13 18:26:52 UYST 2010 <<<<<<<<== BUG (GMT==UTC) Even though date produces UYST on output that doesn't make it suitable for input to the TZ variable. The strings are ambiguous. There are collisions on names of all timezones such that they cannot be used to uniquely identify every timezone. > % un uli /home/uli 6 } setenv TZ CET > % un uli /home/uli 7 } date > Sat Mar 13 19:27:03 CET 2010 > % un uli /home/uli 8 } > > % un uli /home/uli 8 } setenv TZ 'Australia/Perth' > % un uli /home/uli 9 } date > Sun Mar 14 02:39:36 WST 2010 > % un uli /home/uli 10 } setenv TZ WST > % un uli /home/uli 11 } date > Sat Mar 13 18:39:59 WST 2010 <<<<<<<<== BUG (GMT==UTC) > % un uli /home/uli 12 } setenv TZ CET > % un uli /home/uli 13 } date > Sat Mar 13 19:40:10 CET 2010 > % un uli /home/uli 14 } You can gain some insight by looking through the time zone directory in /usr/share/zoneinfo. ls /usr/share/zoneinfo/ You can practically only use timezone names that are specified there. In any case, the date command is simply an interface to glibc and the tzdata set in this case. If a bug were to exist then it would need to be followed up with one of those two respective projects. Bob
