Date: Tue, 26 Apr 2005 12:07:29 -0700 From: Paul Eggert <eggert@CS.UCLA.EDU> Message-ID: <87pswhxspa.fsf@penguin.cs.ucla.edu> | Yes, that would be nice. Thanks. Patch appended. (Patch is to localtime.c in tzcode2005h) | The current POSIX spec for TZ is here (look at the end of the page): Thanks. Bradley White sent me the text in private mail, which was fortunate, as shortly after that I lest net connectivity for a while. | POSIX is a bit more restrictive than the simple spec you gave, Not really - it just says that lots of things are undefined. That's fine, what we do with undefined data is up to us - including when we treat it rationally... | but it'd be fine to implement it the simple way, as an extension to POSIX. That's what I did. That was by analogy with the current (non quoted form) parsing, where posix says 3 or more alphabetic chars, and tzcode allows 3 or more "anything but + - , and digits"). The new quoted code allows 3 or more "anything but >" which is definitely more than "alphanumeric plus '+' and '-'". (All forms disallow \0 of course). However, I'm not real sure that we shouldn't be a little more cautious with this. Do we really want to allow \n in a zone name abbreviation? Might not that cause "unanticipated" problems for some applications (I doubt many bother to sanitise the value of TZ before allowing it to be used). There may be a few other characters that should perhaps be considered "bad" here, without going all the way to alphabetic (current locale alphabetic) or alphanumeric (and + & -) (current locale). I'll leave that for someone else to thing about - and perhaps also to ponder whether there are any programs that could be convinced to do "bad things" by putting "weird stuff" in the zone name abbreviation. kre