Paul Ganssle <p.gans...@gmail.com> added the comment: By the way, one possibly significant problem with this interface is that it would tend to encourage the use of static timezone offsets rather than rule sets as intended by `tzinfo`. The main problem is that a simple mapping between tzname and tzinfo (whether done with a Mapping or a callable) will actually lose information about the fold that is encoded in the chosen tzname.
In dateutil, I solved this problem by attaching the timezone object and checking whether the `.tzname()` of the created datetime matches the string it was parsed from, and if not, set fold=1 and check again - if that one matches, use fold=1, otherwise just return it with fold=0. This is obviously a heuristic metric that will not always work. Two possible more general solutions to this problem: 1. have a variant of `strptime` that returns a `datetime` and the contents of `%Z` and let users or third party libraries handle converting the string into a timezone and attaching it to the datetime. 2. have `tzinfos` take a callable like `handle_tzinfo(dt, tzstr)` which returns the localized datetime. 3. have separate `tzinfos` and `apply_tzinfo` arguments, the first generating the `tzinfo` object, the second of the format `apply_tzinfo(dt, tz)` - if the second one doesn't exist, the default implementation is just `lambda dt, tz: dt.replace(tzinfo=tz)` (or equivalent) #1 is a pretty significant (and possibly awkward) change to the interface, and #2 makes the implementation of these mappings less convenient for the downstream users, but is probably the most elegant from an API perspective. #3 is a somewhat reasonable marriage of #1 and #2, but it's ugly and I'm fairly certain it would lead to a lot of buggy code out there from people who don't realize why you would need to implement the apply function. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32497> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
