At Sat, 16 Apr 2005 16:39:08 +0200, Martin Dickopp wrote: > martin f krafft <[EMAIL PROTECTED]> writes: > > > also sprach Martin Dickopp <[EMAIL PROTECTED]> [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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
