Author brett.cannon
Recipients ajaksu2, belopolsky, brett.cannon, doerwalter, eric.araujo, ggenellina, kawai, pitrou, rafe, vstinner
Date 2010-05-26.00:16:31
SpamBayes Score 0.00840865
Marked as misclassified No
Message-id <1274832995.86.0.151068108933.issue5094@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2010-05-26 00:16:36brett.cannonsetrecipients: + brett.cannon, doerwalter, belopolsky, ggenellina, pitrou, vstinner, ajaksu2, kawai, eric.araujo, rafe
2010-05-26 00:16:35brett.cannonsetmessageid: <1274832995.86.0.151068108933.issue5094@psf.upfronthosting.co.za>
2010-05-26 00:16:34brett.cannonlinkissue5094 messages
2010-05-26 00:16:32brett.cannoncreate