[Python-ideas] Pythonic Dates, Times, and Deltas

Daniel G. Taylor dan at programmer-art.org
Wed Oct 13 23:45:33 CEST 2010

On 10/13/2010 05:17 PM, Alexander Belopolsky wrote:
> On Wed, Oct 13, 2010 at 4:04 PM, Daniel G. Taylor
> <dan at programmer-art.org>  wrote:
>> ... and have run into several annoyances with the
>> built-in datetime, date, time, timedelta, etc classes, even when adding in
>> relativedelta. They are awkward, non-intuitive and not at all Pythonic to
>> me.
> There seems to be no shortage of blogosphere rants about how awkward
> python datetime module is, but once patches are posted on the tracker
> to improve it, nobody seems to be interested in reviewing them.  I has
> been suggested that C implementation presented a high barrier to entry
> for people to get involved in datetime module development.  This was
> one of the reasons I pushed for including a pure python equivalent in
> 3.2.   Unfortunately, getting datetime.py into SVN tree was not enough
> to spark new interest in improving the module.  Maybe this will change
> with datetime.py making it into a released version.

This at least sounds like some progress is being made, so that makes me 
happy. I'd be glad to work on stuff if I knew it has the potential to 
make a difference and be accepted upstream and if it doesn't require me 
rewriting every little thing in the module. I'm not really sure where to 
start as all I really want is a nice wrapper to make working with dates 
seem intuitive and friendly.

> ..
>> My original post about it was here:
>> http://programmer-art.org/articles/programming/pythonic-date
> This post is severely lacking in detail, so I cannot tell how your
> library solves your announced problems, but most of them seem to be
> easy with datetime:

Yeah sorry it was mostly just a frustrated rant and then the start of my 
wrapper implementation.

> * Make it easy to make a Date from anything - a timestamp, date,
> datetime, tuple, etc.
>>>> from datetime import *
>>>> datetime.utcfromtimestamp(0)
> datetime.datetime(1970, 1, 1, 0, 0)
>>>> datetime.utcfromtimestamp(0).date()
> datetime.date(1970, 1, 1)

Why does it not have this in the constructor? Where else in the standard 
lib does anything behave like this? My solution was to just dump 
whatever you want into the constructor and you get a Date object which 
can be converted to anything else via simple properties.

> * Make it easy to turn a Date into anything
> datetime.timetuple() will convert datetime to a tuple.  There is an
> open ticket to simplify datetime to timestamp conversion
> http://bugs.python.org/issue2736

I'll be happy when this is fixed :-)

> but it is already easy enough:
>>>> (datetime.now() - datetime(1970,1,1)).total_seconds()
> 1286989863.82536

This is new in Python 2.7 it seems, before you had to calculate it by 
hand which was annoying to me. Now this seems okay.

> * Make it easy and pythonic to add/subtract one or more days, weeks,
> months, or years
> monthdelta addition was discussed at http://bugs.python.org/issue5434,
> but did not get enough interest.  The rest seems to be easy enough
> with timedetla.

And that means yet another module I have to import with various 
functions I have to use to manipulate an object rather than methods of 
the object itself. This doesn't seem Pythonic to me...

> * Make it easy to get a tuple of the start and end of the month
> Why would you want this?  Start of the month is easy: just date(year,
> month, 1).  End of the month is often unnecessary because it is more
> pythonic to work with semi-open ranges and use first of the next month
> instead.

It's just for convenience really. For an example, I used it for querying 
a database for invoices in certain date ranges and for managing e.g. 
monthly recurring charges. It's just way more convenient and makes my 
code very easy to read where it counts - within the complex logic 
controlling when we charge credit cards. The less complex code there the 
better, because typos and bugs cost real money.

Even if the tuples returned contained e.g. the first day of this and 
next month instead of the last day of the month it's still useful to 
have these properties that return the tuples (at least to me), as it 
saves some manual work each time.

Take care,
Daniel G. Taylor

More information about the Python-ideas mailing list