Hi Marty, Jerome, I saw such widget in time planning apps (Jira bugtracker) and like it very much. When I need to tell that I will work "4 hours" on task, i don't want to see [ 0 ] days [ 4:00:00 ] seconds, and when I tell milestone will long for 6 weeks, i want to see just "1 month 2 weeks", not "[ 42 ] days [ 0:00:00.000 ] seconds", not even "1m 1w 4d 13h 30min 56s 167ms 200us" as it's now. You see, I have a very practical use case too.
Well, I agree that in admin the more formal widget, that Marti suggests, might suit better. As an end user of this functionality, I will be happy iff I will be able to use TimeDelta representation and widget into a field, and change year duration to one that's comfortable to me. On Wed, May 27, 2009 at 12:24 AM, Marty Alchin <[email protected]> wrote: > > Okay, I'm finally back around looking into this situation, and I have > to say I'm not thrilled with the direction it's currently headed. I've > never liked the "1h 30m 10s" syntax in any situation I've ever > encountered it, and I highly doubt that it will be meaningful to much > of anyone. That's personal opinion, of course, but I just don't see it > being a very good solution. My preferred approach would be to simply > separate the days from everything else and let two fields handle it. A > day field would parse an integer, while a time field would parse > standard time syntax ("01:30:10"), which is much more commonly used > for durations. > > I'll freely admit that this isn't perfectly intuitive either, but I > think it's much more natural than the current proposal. I have a > slightly modified version of my original patch that works a bit better > now, and I'm working on a JavaScript helper like the current TimeField > uses in the admin, which should help relieve the intuitiveness > problem. > > More specifically, can someone explain to me just what problems are > solved by adding a custom TimeDelta class? I can only see two benefits > to it: it accepts years and months as units and it maps the new syntax > into meaningful values. I've already spoken on the syntax issue, but > I'd like to point out that accepting years and months is a very bad > idea. > > Basically, there are two ways to deal with years and months, depending > on what situation you're trying to use them in. The first is to not > try to flatten it out to a specific value until applied to a reference > date. This is the approach used by calendar applications, for > instance, when you apply a yearly repeating rule with a start date or > set an alarm for one month in advance of a given event. There are > known reference dates to work with, so years and months can be > calculated accurately. > > The other approach is to assign some approximate value to years and > months, which is especially useful when *not* dealing with reference > dates. For example, you might use this approach to describe a > university degree program that takes four years or a prison sentence > that lasts 6 months. When speaking in generic terms, these > approximations are appropriate, but only because they're abstract in > our minds. They're never given an absolute length of time that can be > collapsed to days, hours, minutes or seconds. That can only happen > once a true date can be assigned. > > What this ticket is doing, however, is trying to formalize the second > approach by explicitly stating some approximate values for years and > months. The intent is admirable, but it's ultimately doomed. What > you're left with is a "solution" that passably works for the second > situation, but outright fails for the first. When a custom TimeDelta > with years and months is applied to a known date, the result will > nearly always be incorrect. All it really does is formalize something > that shouldn't be formalized anyway. > > The third option, which is used by Python and many other computing > systems, is to take years and months out of the equation entirely. > Sure, it's a reduction in functionality, but the benefit is that what > remains *actually works*. Weeks are the largest unit of time that can > be accurately collapsed to seconds on its own and applied to date > calculations in all situations. Thus, Python's timedelta supports > weeks as the largest available unit. > > I saw this issue raised on the ticket, with the response of, "I just > wanted to get the implementation in. It's easier to remove than to > add-on." Unfortunately, there have been two more patches from the same > author and the year and month support remains. I hope I've explained > the situation well enough now that we can forget about years and > months in future patches. > > I'll address the question of input format once I have a new patch up > and running. > > -Gul > > > > -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: [email protected] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
