Hi Jerome,
On Mon, May 25, 2009 at 9:27 AM, Jerome Leclanche <adys...@gmail.com> wrote:
>
> Hi Yuri, thanks for the fixes. Two questions:
>
> - Why mention *args at all (l20,21) if it's to assert they don't exist?
Just to show friendlier user message.
Without args TimeDelta(x) is TimeDelta(days=x) so it tells that what
you passed in can't be in day component.
This was not very clean solution, I just hadn't time to figure out the best way.
datetime.timedelta __new__ method shall have the following signature:
def datetime.timedelta(days=0, seconds=0, microseconds=0): pass
We need to acquire data from "12h 30min" and Decimal("7260000") and
datetime.timedelta and "0" in the most pretty way. Of course the
prettiest is TimeDelta(x).
But if data is days, and is int, say "5", we should let existing code work.
I didn't manage to solve this puzzle in those 5 minutes I had for it.
TimeDelta(from=None, days=0, seconds=0, microseconds=0)
will break days handling if anyone will change the datetime.timedelta
into TimeDelta.
So, the best I found was something like
TimeDelta(*args, days=0, seconds=0, microseconds=0) and processing
args by myself.
But since I hadn't much time, I asserted *args to make sure I'm not
using TimeDelta().
That's how I forgot about days handling idea with TimeDelta(5, 3, 1).
After few days passed, I tend to think the best is the most explicit:
TimeDelta(days=0, seconds=0, microseconds=0, from=None)
Changing gist now.
> - Any idea where to put the TimeDelta class? I still don't believe it
> belongs in django.widgets, but I'm not familiar enough with the
> structure to know where to put it.
Somewhere in django.utils, I believe, but from_timetuple method should
move into constructor too, and a single line should stay in
from_timetuple.
> Cheers, I'll try the patch tomorrow.
>
> Jerome
>
> On Mon, May 25, 2009 at 4:12 AM, Yuri Baburov <burc...@gmail.com> wrote:
>>
>> Hi Adys,
>>
>> I solved this problem, wrapping datetime.timedelta into custom TimeDelta.
>> Now everything works: http://gist.github.com/117307
>>
>> Also altered microseconds in one month value so 12 * month are equal to 1
>> year.
>> This fixes "13m" bug (breaking into smaller parts incl. microseconds).
>> "31d" bug is still there.
Any idea if "31d" bug should be fixed?
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
