> I don't think we are going to support a timezone list like that without PEP 431.

PEP 431 won't fix this issue. See below.

> You should attach your patch to a new issue.  When I said this should
> the doc issue, that is because only a doc fix is acceptable for 3.4.
> Adding more timezones to recognize would be an enhancement, given the
> complexity of the proposed solution.

The docs are correct (they imply that %Z should accept EST). It is the
implementation that is deficient.

The patch introduces a new parameter therefore I agree: it should be
applied only in 3.5+

> On the other hand, if timezone names are ambiguous, I'm not sure there
> *is* a fix other than using the "defacto standard" names and offsets
> used by the email library.  Actually, isn't there a written standard
> that addresses this issue?  I seem to remember reading a discussion of
> the problem somewhere...

Multi-timezone programming

email._parseaddr._timezones with CST=-600 is like US-ASCII (the
standard). 

Code that uses local timezone is bilingual (locale-based): CST=-600 in
Chicago but it is CST=+800 in China and it may be something else in
other parts of the world. The *timezones* parameter in my patch allows
to specify the encoding different from the current locale.

Code that uses the tz database is multilingual (Unicode): knowing the
encoding (zoneinfo name and the time) it is possible to decode almost
all encoded characters (to find out whether the timezone abbreviation is
valid with a given time and to find the correct UTC offset).

If you don't know the encoding then the support for Unicode (the
presence of the tz database (PEP 431)) along won't allow you to decode a
byte sequence (time string). You need an encoding (timezone name, time)
to interpret the input correctly.

Given that the list is used to accept a string as a timezone
abbreviation, I don't think it should depend on PEP 431 e.g., old date
strings/people may use WST even if the new pytz timezones do not use it.

The initial list could be seeded from using pytz as in my patch and then
expanded as necessary by hand (there is no official entity that tracks
timezone abbreviations).