[Python-Dev] datetime module enhancements (original) (raw)

Brett Cannon brett at python.org
Sat Mar 10 03:31:26 CET 2007

On 3/9/07, Christian Heimes <lists at cheimes.de> wrote:

Collin Winter schrieb: > I can't say I'm well-versed in the intricacies of date/time issues, > but what you say makes sense. This is exactly why I brought this patch > up here : )

Oh h...! Seems like I've opened a can of worms here. I only wanted to add some minor enhancements and now it looks like the improvements and the datetime module have to be carefully defined and PEPed. I'm trying to summarize the discussed issues and proposals: * Change the underlying timet type (Unix timestamp) to use a unsigned 64bit integer even on 32 bit operating systems. * Carefully define the comparison between date and datetime objects. * int(timedelta) and float(timedelta) returns seconds * Add methods to datetime to cast from/to Julian Date Number (also MJD and RJD) * What about moving the C extension to datetime so we can implement some non time consuming extensions in Python?

When a use-case comes up we can make the move, but we don't need to do it pre-emptively.

* What do you think about including PyTz in the Python core? PyTz is really, REALLY useful when one has to deal with time zones. http://pytz.sourceforge.net/

What is wrong with datetime's tzinfo objects? You need to show why datetime is not sufficient and why fixing it is not worth it and how it is better to bring in another chunk of code. And then we can discuss code standards, the author of PyTz stepping forward to contribute the code and maintain it, etc.

* The dateutil package contains additional features which may prove as useful: http://labix.org/python-dateutil

If someone wants to port features from dateutil to datetime, that's fine, but they just need to be worth it.

-Brett

More information about the Python-Dev mailing list