Oh, disregard the second question, I wasn't fully awake :-) J
On Mon, May 25, 2009 at 5: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? > - 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. > > 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. >> >> On Sat, May 9, 2009 at 8:33 AM, Adys <[email protected]> wrote: >>> >>> Hi all >>> >>> I've been working on DurationFields this evening (ticket #2443)[1]. My >>> implementation is working pretty well with a single TextInput. I'm >>> storing the durations as Decimal in the database (since from what I've >>> heard storing them as a 64-bit int is a no-go), in microseconds. >>> When creating or modifying a DurationField, the user can either use >>> ints/floats/float strings which will be interpreted as seconds, or use >>> a datetime.timedelta object. >>> In the admin (this will need some inline help or similar), users have >>> a single text input, which lets them type durations as, for example >>> "1w" for 1 week, "1h 30min", or even "1y 7m 6w 3d 18h 30min 23s 10ms >>> 150mis" (in order of all accepted values). The values don't have to be >>> in a specific order and a repeated one will be accounted both times >>> (10d 1h 5d will be 15d 1h). >>> >>> What I need help with: >>> - The admin output is the result of a str(timedelta), I haven't >>> figured out how to use from_timedelta() on the value; so for now a >>> DurationField will show "10 days, 0:00:00" when it should show "10d". >>> - Moving from_timedelta, to_timedelta and values_in_milliseconds >>> elsewhere. They are reusable for other similar fields and don't belong >>> where I coded them. But I'm not familiar with Django, and I don't know >>> where they should be. Somewhere in django.utils? >>> - Any unnecessary code I haven't spotted. My patch is based on the >>> previous DurationField implementation which dates from pre 1.0, I'm >>> unsure if there's anything not necessary anymore. >>> - Any comment on the code, the implementation, etc is appreciated. >>> However I haven't sent other Django patches before, be nice :-) >>> >>> Thanks. >>> >>> Jerome >>> >>> [1] The patch: >>> http://code.djangoproject.com/attachment/ticket/2443/durationfield-new.diff >>> > >>> >> >> >> >> -- >> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, >> MSN: [email protected] >> >> >> >> > > > > -- > Adys > -- 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 -~----------~----~----~----~------~----~------~--~---
