[Python-ideas] Pythonic Dates, Times, and Deltas (original) (raw)

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)).totalseconds() 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 http://programmer-art.org/

More information about the Python-ideas mailing list