Gul, appreciate the feedback.
Right now, removing months and years is a matter of removing two lines
from the patch. I didn't want to write a patch just to get told "it's
lacking months/years!"; I'm also in favour of dropping it and
following Python's style; but up until now no one except yourself and
Yuri have given feedback, I had no reason to drop it.
As for the current syntax, I believe with a small syntax helper
somewhere next to the field, this would be and feel completely
natural. 01:30:10 is a bit meaningless if you're not working in
seconds. One of my application uses standard milliseconds durations,
would I have to write 01:30:10.5 to have another 500ms? Would I need
1-2 other fields for milli/microseconds - which would make us go back
to the former problem ("Many input boxes is not a nice user
experience")?
That's the way I was going until someone came up with the idea of
parsing a timestring. Looking back, this is much more elegant, as long
as the user knows what to do. The need for a javascript helper is
entirely dropped since it's extremely easy to input any kind of value,
and the user doesn't have to convert any kind of value. If the user
wants 17 weeks, they just input "17w" instead of having to calculate
119 days. If they want "1500 seconds", same thing; so on.
Also remember not everyone has javascript enabled.
As for a wrapper TimeDelta class, that's up to Yuri to explain - I
don't see the problem with it personally.
Cheers,
Jerome L.
On Tue, May 26, 2009 at 8:24 PM, 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
>
> >
>
--
Adys
J. Leclanche
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
