[Python-Dev] datetime module enhancements

[Brett Cannon]

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 time_t 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