This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author akira
Recipients akira, belopolsky, berker.peksag, cool-RR, r.david.murray
Date 2014-09-17.03:54:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1410926091.27.0.508875437003.issue22377@psf.upfronthosting.co.za>
In-reply-to
Content
If the current implementation is considered correct (%Z not recognizing
EST) then indeed extending the list of recognized timezones is another
issue. And the docs should be changed to match the implementation.

The current behavior is broken, see also issue22426

If we assume that the docs are correct (%Z should match EST) even if it
is not implemented yet then it is this issue's responsibility to extend
the list of recognized timezones (even an incomplete hard-coded list
generated by the code from msg226857 would be fine).

Lib/email/_parseaddr.py approach (tzname corresponds to a fixed utc
offset) is wrong: tzname may correspond to multiple utc offsets at the
same time (different timezones) and at different times (even within the
same timezone). Having the tz database won't fix it: *tzname along is
not enough to determine UTC offset in _many_ cases.*


CST is ambiguous if %z is not given therefore even if strptime() had the
access to a larger list of recognized timezones; it is not clear what
the return value would be:

- aware datetime: which timezone to use?

- naive datetime: it might be misleading if the input timezone name
  doesn't correspond to utc or the local timezone

email._parseaddr._timezones is misleading if used globally: CST is also
used in Australia, China with different utc offsets.

One of possible solutions is to return aware datetime objects if a new
truthy *timezones* keyword-only argument is provided. It may contain a
mapping to disambiguate timezone abbreviations: {'EST': timedelta|tzinfo}.

If *timezones* is False then strptime() returns a naive datetime
object. The only difference from the current behavior is that a larger
list of timezones is supported to match the docs.

With bool(timezones) == True, strptime() could return an aware datetime
object in utc, local timezones, or any timezone in *timezones* if it is
a mapping.

Default *timezones* is None that means timezone=False for backward
compatibility. DeprecationWarning is added that timezone=True will be
default in the next release 3.6 if no objections are received
until then e.g.,

    if tzname and timezones is None: # %Z matches non-empty string
        warn("Default *timezones* parameter for "
             "%s.strptime() will be True in Python 3.6. "
             "Pass timezones=False to preserve the old behaviour" % (
                 cls.__qualname__,),
             category=DeprecationWarning, stacklevel=2)

I've uploaded the patch draft-strptime-%Z-timezones.diff that implements
this solution. It also contains tests and docs updates.
History
Date User Action Args
2014-09-17 03:54:53akirasetrecipients: + akira, belopolsky, r.david.murray, cool-RR, berker.peksag
2014-09-17 03:54:51akirasetmessageid: <1410926091.27.0.508875437003.issue22377@psf.upfronthosting.co.za>
2014-09-17 03:54:51akiralinkissue22377 messages
2014-09-17 03:54:50akiracreate