Brett Cannon <br...@python.org> added the comment: OK, it looks like we are reaching consensus here on several points:
1. Implement FixedOffsetTimezone 2. Provide a utc attribute on the datetime module that is set to ``FixedOffsetTimezone(0, "UTC")`` 3. Deprecate the various utc* methods with messages pointing out how to use the new utc instance instead of the method If this seems reasonable, then I see two questions to answer. First is how long to do the deprecations. I say remove in Python 3.5. Existing for three versions is six more years of usage from the time of 3.2's release to that of 3.6. Plus it is easy to be backwards-compatible by showing in the docs how to create one's own UTC class. The second is whether we should take this opportunity to fix datetime being a C extension module exclusively. I know PyPy has their own pure Python version of datetime that they plan to eventually contribute. We might as well use this as the chance to create Lib/datetime.py and have that conditionally import _datetimemodule.c (see the heapq module on how to handle this kind of situation). That way PyPy can eventually just drop their code into datetime.py. Biggest issue will be extension modules wanting to use the C extension API, but since this is new stuff it shouldn't affect them except for the module renaming. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5094> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
