Re: Bug#271428: mapping unknown timezones

[GOTO Masanori <gotom@debian.or.jp>]

At Sat, 16 Apr 2005 16:39:08 +0200,
Martin Dickopp wrote:
> martin f krafft <madduck@debian.org> writes:
> 
> > also sprach Martin Dickopp <martin@zero-based.org> [2005.04.16.1552 +0200]:
> >> Therefore, any actual behavior (including the existing one as well
> >> as the suggested alternatives) would be standard conforming.
> >
> > I don't think I was criticising standards compliance...
> 
> I didn't mean to say you did. But after reading the postings to the bug
> report (well, to be honest, after skimming them quickly... :) ), it
> seemed that nobody had yet looked up if the relevant standards do in
> fact mandate any specific behavior for the case of an invalid TZ, so I
> did that first. Apologies if I have missed something.

I agreed to Dickopp (you read the standard in detail).  This is the
implementation dependent behavior.

At Sat, 16 Apr 2005 14:57:15 +0200,
martin f krafft wrote:
> If libc does not know the timezone you request, it should *not* fall
> back to GMT and claim that it is rendering the requested timezone.

Read tzset() and think again.  POSIX defined tzset() that affects
timezone related functions does not return any error value.

> If you ask me, it should do either of the following, in decreasing
> order of my preference:
> 
>   cirrus:~> TZ=GOTO date
>   W: unknown timezone: GOTO. Using UTC instead.
>   Sat Apr 16 12:48:31 UTC 2005
> 
>   cirrus:~> TZ=GOTO date
>   Sat Apr 16 12:48:31 UTC 2005
> 
>   cirrus:~> TZ=GOTO date
>   E: unknown timezone: GOTO.
>   
> Now, whether this is a strftime problem, or how to incorporate the
> above into strftime is not my concern. I am a user and not willing
> to figure out the libc dungeons. I just note that the current
> behaviour of date is misleading, and that is what this bug is all
> about.

You became aware that you implicated two different concept - libc
functions vs date command utilities.  As I wrote repeatedly, it's hard
to distinguish the timezone correctness with the current standard libc
functions.

If your wish is just for date command, and you did not request to
change the current libc standard behavior, we can propose other fixes.
The simplest idea is to use strptime and parse them, and check the
validity.  Another idea is to create new function tzvalid() that
inspects the validity of timezone value.  Other idea is date command
parses /usr/share/timezone directory - it's a bit ugly change, though.

Regards,
-- gotom