Juergen Weigert <[EMAIL PROTECTED]> writes: > $ env TZ=MDT date > Mon Sep 19 17:52:53 MDT 2005 > --> wrong. > > Oops, now difference is 7 hours ... > The problem here is, that MDT is an unknown timezone on my machine. > Date silently defaults back to GMT, but it keeps the label 'MDT'.
"date" is merely outputting the time zone information given by the localtime function of the C library, so the behavior you're observing is a property of the C library, not of coreutils. For example, on Solaris 10 with coreutils 5.3.0, we get this: $ TZ=MDT date Tue Sep 20 18:59:58 GMT 2005 > The first bug here may be that env TZ=US/Mountain date prints a timezone > name that it cannot use as its own input. That's not a bug, since strftime's %Z format isn't supposed to output a time zone abbreviation that is acceptable as a TZ value. It would be impossible for it to do so in general; for example, the abbreviation "EST" has different meanings in Australia and the US. > The second and IMHO more serious bug is that invalid input is not > recognized as such, and thus very misleading output is generated. I agree that it's a problem, but this is a C library issue, not a coreutils issue, so it's a matter that would need to be taken up with the GNU C library. It's longstanding tradition that invalid TZ values act like UTC, so I suspect at most you'll get a change to have strftime %Z output "GMT" (like Solaris 10) or "UTC" (probably better these days) rather than the TZ string value. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils