On Fri, Jul 11, 2008 at 03:04:50PM +0200, you wrote:
also sprach Debian Bug Tracking System <[EMAIL PROTECTED]> [2008.07.11.1454
+0200]:
No, date can't do that because TZ is neither the only nor the primary way
to set the time zone. The details of how the timezone is set is not
date's business. Now that the default output gives an indication that a
bogus timezone setting is being ignored I think the bug can be closed.
I disagree, but I won't play bug ping pong.
Please explain what you think date should be doing, then. If there were
a libc API for "what is the currently configured timezone and is it
invalid" I'd use it. But I think it's stupid to try to guess whether
there's a discrepency between the configured timezone and the active
timezone, especially in a portable program. The only part of the system
which knows for sure what libc's rules are for evaluating the timezone
config is libc.
(I.e., should I look at ENV{TZ}? /etc/localtime?
/usr/share/zoneinfo/localtime? I remember a time before /usr/share even
existed--should date try to guess whether it's /usr/share or /usr/lib
based on strings in libc? Which libc? What do I do if I'm statically
linked against a different libc? What happens if libc is upgraded but
date isn't and date gives incorrect warning messages because it doesn't
understand libc's new behavior? What if the user is properly utilizing
POSIX-mandated zone syntax [e.g.:
> env TZ=QQQ5:10QDT4:10,J70/4,J300/2 date
Fri Jul 11 09:35:36 QDT 2008
] which would require a lot of otherwise unnecessary and likely
error prone parsing for date to understand? And all this should be
implemented in date(1) for something which affects any program which
uses libc's time functions? I think there is a real case for a timezone
configuration validation/explanation tool, but it should be provided by
the libc API and tightly coupled to the libc implementation.)
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
