Re: Bug#271428: mapping unknown timezones
martin f krafft <madduck@debian.org> writes:
> Sending to debian-devel because I would like to hear other people's
> opinions. It's about #271428, as the subject says. Please keep
> 271428-quiet@bugs.debian.org on CC (I assume GOTO reads -devel).
>
> also sprach GOTO Masanori <gotom@debian.or.jp> [2005.04.16.1421 +0200]:
>> Exactly, the problem is strftime. If you want to change it,
>> please propose it - such new function might be GNU specific
>> interface.
>>
>> BTW, I think it's not buggy because it has been used for a long
>> time on various unix. It seems you're eager to have new strftime
>> - why don't you work for it?
>
> We are running in circles. Just because something has been used for
> a long time does not mean it is be bug free.
>
> 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.
>
> cirrus:~> TZ=GOTO date
> Sat Apr 16 12:48:31 GOTO 2005
>
> is wrong. It is not 12:48 in the GOTO timezone because the GOTO
> timezone does not exist.
>
> 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.
According to my understanding of the POSIX 2001 standard, the behavior
is undefined if TZ is set to an invalid value. (ISO C 99 does not
specify how the timezone is determined, but some vague wording [in
section 7.23.3.5p3, description of %z and %Z] suggests that it can be
either determinable or not determinable.)
Therefore, any actual behavior (including the existing one as well as
the suggested alternatives) would be standard conforming.
>From a QoI point of view, I'd prefer if the timezone string is emitted
as "UTC". I have no opinion whether 'date' should print a warning, but
IMHO 'strftime' should /not/ write to standard output or standard error.
Martin
Reply to: