I'm not sure what you mean by 31d bug. When I input "31d", I get a
value of "1m 13h 30min 56s 167ms 200us", which is the correct
duration. (=> http://www.google.com/search?q=how+many+days+in+a+month
).
The problem of breaking into smaller parts is that a month isn't an
integer amount of days; if it needs fixing, it should probably check
if the value is equal to an integer amount of months/years first, then
check if it's equal to an integer amount of days:
- Yes / (No|Yes): Display as month/year
- No / No: Break into parts (current behaviour)
- No / Yes: Display as days
Another thing I noticed this morning: When using a DurationField as
filter into the admin, I get values in microseconds rather than the
"prettified" version. e.g.:
By duration
* All
* 0
* 20000000
* 30000000
* 60000000
* 180000000
* ...
I updated the patch on ticket #2443 earlier today to apply cleanly to
current trunk. It's the one I've been using today and I haven't found
any other issue.
On Tue, May 26, 2009 at 7:44 PM, Yuri Baburov <[email protected]> wrote:
>
> Hi Jerome,
>
> On Mon, May 25, 2009 at 9:27 AM, Jerome Leclanche <[email protected]> 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 <[email protected]> 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: [email protected]
>
> >
>
--
Adys
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
