[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: date misbehaves with illegal timezones
From: |
Paul Eggert |
Subject: |
Re: date misbehaves with illegal timezones |
Date: |
Tue, 20 Sep 2005 12:09:02 -0700 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) |
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.