Re: date misbehaves with illegal timezones

[Paul Eggert]

Juergen Weigert <address@hidden> 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.