I am cc'ing python-dev at Tim's suggestion. You can read the replies in the email, but the gist is whether time.strptime() should accept UTC and GMT for teh %Z directive. [Tim Peters]
[Brett Cannon]
I was writing a script using strptime and I rediscovered that strptime (at least the pure Python version) does not accept UTC for the %Z directive as an acceptable timezone.
Is it that it specifically didn't accept UTC, or that it generally doesn't accept anything for %Z?
Doesn't accept anything beyond what the computer's timezone is (if the computer is in PDT, it only picks that up and nothing else; quick test I did failed on PST). So trying anything that is not directly known gets rejected as a format error.
Now I just checked an install on a Solaris machine under Python 2.2 and it doesn't accept UTC as a timezone either so I know of at least one C version that doesn't take it either.
Do you two think that I should modify strptime to accept UTC and GMT and then set tm_isdst (DST flag) to 0? Or should it just stay as-is and not accept it? Should I change it so that it accepts any 3-letter entry for %Z and then just see if I know what the timezone is; if I know set tm_isdst appropriately, otherwise set it to -1?
I say yes to adding UTC and no to blindly accepting possible timezones. My feeling is that this should act as closely to a naive datetime representation as possible.
And don't let having to deal with a patch hold you up on wanting to change it; I have to patch a "feature" of strptime anyway. =)
I think you should debate this in public.
So if you guys don't like hearing about this stuff blame Tim. =)
%Z isn't allowed in POSIX strptime(). GNU docs say glibc supports it as an extension to POSIX, and that GNU "parses" for it (whatever that means), but that "no field in tm is changed" as a result. A number of other strptime man pages on the web say:
%Z timezone name or no characters if no time zone information exists
which suggests they carelessly copied the format part of their strftime() man page.
So there's no clear prior art to follow here, and inventing new art takes more time than I have (hence "debate this in public" -- please <wink>).
Well, that man page line is pretty much what the Python docs say. Personally I would love to not have to support it, but it has been in the docs so I don't know if we can yank it without upsetting someone (although strptime has always been questionable, so maybe we can rip it out). So, "public", should strptime be able to handle UTC and GMT as a timezone no matter what? How about taking in any 3-character timezone so that an error isn't raised but only set the DST flag if it is a known timezone? Perhaps %Z should accept 42 since it is the answer to everything? -Brett