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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
