search

johnpaulett / django-durationfield

Temporary reusable Django application for adding a DurationField, until Django issue #2443 is resolved.
http://django-durationfield.readthedocs.org
67 stars 24 forks source link

Fate of the 'poswald/exp-timedelta-internal' branch #4

Closed poswald closed 13 years ago

poswald commented 13 years ago

So… a while back I created an experimental branch ( poswald/django-durationfield@exp-timedelta-internal ) that would use the python timedelta type as the native type returned to code calling this field. I figured that it might be nicer to use the native python type.

It turns out that the python timedelta is type is not a 100% slam dunk choice. The way it stores time as days, seconds, microseconds is a bit unconventional and the input/output methods available are somewhat limited.

That being said, it's the version I use most often and a few people have forked it. I got to thinking on how to reconcile this and I was considering perhaps it should be an alternate field or widget in the project, not just a fork. I'd like to know if anyone has any thoughts about this.

I'm opening this issue here rather than on my own branch since as the original version, more people watch yours.

johnpaulett commented 13 years ago

I do like the idea of using timedelta. It does seem more useful (you can easily do calculations with datetimes).

While timedelta's storage can feel clunkly, I think it is better than the solution in my master branch, which returns an integer number of microseconds (which likely needs to be transformed into some other units anyway).

Unless others object, I will probably switch to your timedelta branch once I get a chance to go over the code once more.

poswald commented 13 years ago

Another option I was considering using was the Labix RelativeDelta type:

http://labix.org/python-dateutil

It seems a bit more powerful than the python type but I have little experience with it. Does anyone reading have experience with it?

johnpaulett commented 13 years ago

The primary downside I see is just adding a dependency.

If the goal is still to get this code eventually merged into django-core, I am not sure they would want to add a dependency. Though, if the labix package is significantly helpful, maybe it makes sense to not worry about merging.

johnpaulett commented 13 years ago

It looks like everyone favors the timedelta approach. i have merged the branch, update the docs, and release 0.3.0 based upon timedeltas. Thanks poswald!

By adding connection=None to some of the DurationField's methods, it looks like we can get Django 1.1-1.3 support on a common code base.