Akira Li added the comment: > 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). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22377> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com