Re: [Python-Dev] Issue5434: datetime.monthdelta
On Thu, Apr 16, 2009 at 8:01 PM, Jess Austin jess.aus...@gmail.com wrote: These operations are useful in particular contexts. What I've submitted is also useful, and currently isn't easy in core, batteries-included python. While I would consider the foregoing interpretation of the Zen to be backwards (this doesn't add another way to do something that's already possible, it makes possible something that currently encourages one to pull her hair out), I suppose it doesn't matter. If adding a class and a function to a module will require extended advocacy on -ideas and c.l.p, I'm probably not the person for the job. If, on the other hand, one of the committers wants to toss this in at some point, whether now or 3 versions down the road, the patch is up at bugs.python.org (and I'm happy to make any suggested modifications). I'm glad to have written this; I learned a bit about CPython internals and scraped a layer of rust off my C skills. I will go ahead and backport the python-coded version to 2.3. I'll continue this conversation with whomever for however long, but I suspect this topic will soon have worn out its welcome on python-dev. I've uploaded the backported python version source distribution to PyPI, http://pypi.python.org/pypi?name=MonthDelta:action=display with better-formatted documentation at http://packages.python.org/MonthDelta/ easy_install MonthDelta works too. cheers, Jess ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
On 2009-04-16 21:55, s...@pobox.com wrote: Jess If, on the other hand, one of the committers wants to toss this in Jess at some point, whether now or 3 versions down the road, the patch Jess is up at bugs.python.org (and I'm happy to make any suggested Jess modifications). Again, I think it needs to bake a bit. I understand the desire and need for doing date arithmetic with months. Python is mature enough though that I don't think you can just toss this in. It should be available as a module outside of Python so people can beat on it, flush out bugs, make suggestions for enhancements, whatever. I believe you mentioned putting it up on PyPI. I think that's an excellent idea. I've used parts of Gustavo Niemeyer's dateutil package for a couple years and love it. It's widely used. Adding it to dateutil seems like another possibility. That would guarantee an instant user base. From there, if it is found to be useful it could make the leap to be part of the datetime module. dateutil.relativedelta appears to do everything monthdelta does and more in a general way. Adding monthdelta to dateutil doesn't seem to make much sense. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
-On [20090417 04:55], s...@pobox.com (s...@pobox.com) wrote: Again, I think it needs to bake a bit. I understand the desire and need for doing date arithmetic with months. Python is mature enough though that I don't think you can just toss this in. It should be available as a module outside of Python so people can beat on it, flush out bugs, make suggestions for enhancements, whatever. I think people should look at mx.DateTime a bit, including its documentation. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B To do injustice is more disgraceful than to suffer it... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
Jess Austin jess.austin at gmail.com writes: I have worked in utility/telecom billing, and needed to examine large numbers of invoice dates, fulfillment dates, disconnection dates, payment dates, collection event dates, etc. There would often be particular rules for the relationships among these dates, and since many companies generate invoices every day of the month, you couldn't rely on rules like this always happens on the 5th. But, as you say, these are /particular rules/. Why do you think they would be the same in another industry, or even another telecom company? Why should they be integrated in Python's standard distribution? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
2rd of March on leap years, ^^^ The turd of March? Yeah, it's from a little known Shakespearean play about a benevolent dictator, Guidius van Rossumus. The name of the play escapes me at the moment, but there's this critical scene where the BDFL is in mortal danger because of ongoing schemes by the members of the PSU. His one true friend and eventual replacement, Barius Warsawvius, known as the FLUFL, tries to warn him surreptitiously about the dangers lurking all about. Barius utters this immortal quote, Beware the Turd of March. Unfortunately, the drama of that scene tends to be lost on modern audiences. Upon hearing that famous utterance they tend to break out in laughter, especially if the audience is made up mostly of boys under the age of twelve. -- Skip Montanaro - s...@pobox.com - http://www.smontanaro.net/ XML sucks, dictionaries rock - Dave Beazley ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
It's not only about what people find intuitive. Why care about them? Most persons aren't programmers. It is about what application developers find useful too. I have often needed to calculate month deltas according to the proposal. I suspect many other programmers have too. Writing a month add function isn't entirely trivial and would be a good candidate for stdlib imho. 2009/4/17, Antoine Pitrou solip...@pitrou.net: James Y Knight foom at fuhm.net writes: It's a human-interface operation, and as such, everyone (ahem) knows what it means to say 2 months from now, but the details don't usually have to be thought about too much. I don't think it's true. When you say 2 months from now, some people will think 9 weeks from now (or 10 weeks from now), others 60 days from now, and yet other will think of the meaning this proposal gives it. That's why, when scheduling a meeting, you don't say 2 months from now. You give a precise date instead, because you know otherwise people wouldn't show up on the same day. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/bjourne%40gmail.com -- mvh Björn ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
On Fri, Apr 17, 2009, BJ?rn Lindqvist wrote: It's not only about what people find intuitive. Why care about them? Most persons aren't programmers. It is about what application developers find useful too. I have often needed to calculate month deltas according to the proposal. I suspect many other programmers have too. Writing a month add function isn't entirely trivial and would be a good candidate for stdlib imho. At this point, further discussion really needs to move to python-ideas; for acceptance in stdlib, there needs to be either well-accepted code out in the community or a PEP for Guido to pronounce on (or probably both, in the end). I've set followups to python-ideas for convenience. -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ If you think it's expensive to hire a professional to do the job, wait until you hire an amateur. --Red Adair ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Issue5434: datetime.monthdelta
hi, I'm new to python core development, and I've been advised to write to python-dev concerning a feature/patch I've placed at http://bugs.python.org/issue5434, with Rietveld at http://codereview.appspot.com/25079. This patch adds a monthdelta class and a monthmod function to the datetime module. The monthdelta class is much like the existing timedelta class, except that it represents months offset from a date, rather than an exact period offset from a date. This allows us to easily say, e.g. 3 months from now without worrying about the number of days in the intervening months. date(2008, 1, 30) + monthdelta(1) datetime.date(2008, 2, 29) date(2008, 1, 30) + monthdelta(2) datetime.date(2008, 3, 30) The monthmod function, named in (imperfect) analogy to divmod, allows us to round-trip by returning the interim between two dates represented as a (monthdelta, timedelta) tuple: monthmod(date(2008, 1, 14), date(2009, 4, 2)) (datetime.monthdelta(14), datetime.timedelta(19)) Invariant: dt + monthmod(dt, dt+td)[0] + monthmod(dt, dt+td)[1] == dt + td These also work with datetimes! There are more details in the documentation included in the patch. In addition to the C module file, I've updated the datetime CAPI, the documentation, and tests. I feel this would be a good addition to core python. In my work, I've often ended up writing annoying one-off add-a-month or similar functions. I think since months work differently than most other time periods, a new object is justified rather than trying to shoe-horn something like this into timedelta. I also think that the round-trip functionality provided by monthmod is important to ensure that monthdeltas are first-class objects. Please let me know what you think of the idea and/or its execution. thanks, Jess Austin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
Hi Jess, I'm sorry if I'm failing to understand the use of this function from not looking closely at your code. I'm a bit dubious about the usefulness of this (I'm not sure I understand the use cases), but I'm very open to being convinced. Datetime semantics are very important in some areas -- I use them a lot. I'm not convinced the semantics of monthdelta are obvious. A month doesn't have a consistent length -- it could be 28, 29, 30 or 31 days. What happens when you ask for the date in 1 month's time on the 31st Jan? What date is a month after the 31st Jan? Do you have a good spec (er, I mean PEP) for this describing what happens in the edge cases and what is meant by a monthdelta? The bug notes say it deals sensibly with these issues, but that's really not enough to understand what the function is likely to do. At the very least, a few well-chosen examples would help to illustrate the functionality much more clearly. Cheers, -Tennessee On Thu, Apr 16, 2009 at 4:18 PM, Jess Austin jess.aus...@gmail.com wrote: hi, I'm new to python core development, and I've been advised to write to python-dev concerning a feature/patch I've placed at http://bugs.python.org/issue5434, with Rietveld at http://codereview.appspot.com/25079. This patch adds a monthdelta class and a monthmod function to the datetime module. The monthdelta class is much like the existing timedelta class, except that it represents months offset from a date, rather than an exact period offset from a date. This allows us to easily say, e.g. 3 months from now without worrying about the number of days in the intervening months. date(2008, 1, 30) + monthdelta(1) datetime.date(2008, 2, 29) date(2008, 1, 30) + monthdelta(2) datetime.date(2008, 3, 30) The monthmod function, named in (imperfect) analogy to divmod, allows us to round-trip by returning the interim between two dates represented as a (monthdelta, timedelta) tuple: monthmod(date(2008, 1, 14), date(2009, 4, 2)) (datetime.monthdelta(14), datetime.timedelta(19)) Invariant: dt + monthmod(dt, dt+td)[0] + monthmod(dt, dt+td)[1] == dt + td These also work with datetimes! There are more details in the documentation included in the patch. In addition to the C module file, I've updated the datetime CAPI, the documentation, and tests. I feel this would be a good addition to core python. In my work, I've often ended up writing annoying one-off add-a-month or similar functions. I think since months work differently than most other time periods, a new object is justified rather than trying to shoe-horn something like this into timedelta. I also think that the round-trip functionality provided by monthmod is important to ensure that monthdeltas are first-class objects. Please let me know what you think of the idea and/or its execution. thanks, Jess Austin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/tleeuwenburg%40gmail.com -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ Don't believe everything you think ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
On Thu, Apr 16, 2009 at 01:18:01AM -0500, Jess Austin wrote: I'm new to python core development, and I've been advised to write to python-dev concerning a feature/patch I've placed at http://bugs.python.org/issue5434, with Rietveld at http://codereview.appspot.com/25079. I have read the python code and it looks good. I often have a need to do month-based calculations. This patch adds a monthdelta class and a monthmod function to the datetime module. The monthdelta class is much like the existing timedelta class, except that it represents months offset from a date, rather than an exact period offset from a date. I'd rather see the code merged with timedelta: timedelta(months=n). Oleg. -- Oleg Broytmannhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
date(2008, 1, 30) + monthdelta(1) datetime.date(2008, 2, 29) What would this loop would print? for d in range(1, 32): print date(2008, 1, d) + monthdelta(1) I have this funny feeling that arithmetic using monthdelta wouldn't always be intuitive. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
On Apr 16, 2009, at 1:10 AM, Oleg Broytmann wrote: This patch adds a monthdelta class and a monthmod function to the datetime module. The monthdelta class is much like the existing timedelta class, except that it represents months offset from a date, rather than an exact period offset from a date. I'd rather see the code merged with timedelta: timedelta(months=n). +1 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
On Thu, Apr 16, 2009 at 10:45, s...@pobox.com wrote:
date(2008, 1, 30) + monthdelta(1)
datetime.date(2008, 2, 29)
What would this loop would print?
for d in range(1, 32):
print date(2008, 1, d) + monthdelta(1)
I have this funny feeling that arithmetic using monthdelta wouldn't always
be intuitive.
FWIW, the Oracle database has two methods for adding months:
1- the add_months() function
add_months(to_date('31-jan-2005'), 1)
2- the ANSI interval:
to_date('31-jan-2005') + interval '1' month
add_months is calendar sensitive, interval is not.
interval raises an exception if the day is not valid for the target
month (which is the case in my example)
add_months is similar to the proposed monthdelta(),
except that it has a special case for the last day of the month:
If date is the last day of the month or if the resulting month has
fewer days than the day
component of date, then the result is the last day of the resulting month.
Otherwise, the result has the same day component as date.
indeed:
add_months(to_date('28-feb-2005'), 1) == to_date('31-mar-2005')
In my opinion:
arithmetic with months is a mess. There is no such month interval or
year interval with a precise definition.
If we adopt some kind of month manipulation, it should be a function
or a method, like you would do for features like last_day_of_month(d),
or following_weekday(d, 'monday').
date(2008, 1, 30).add_months(1) == date(2008, 2, 29)
--
Amaury Forgeot d'Arc
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
On Thu, Apr 16, 2009 at 11:54, Amaury Forgeot d'Arc amaur...@gmail.com wrote: In my opinion: arithmetic with months is a mess. There is no such month interval or year interval with a precise definition. If we adopt some kind of month manipulation, it should be a function or a method, like you would do for features like last_day_of_month(d), or following_weekday(d, 'monday'). date(2008, 1, 30).add_months(1) == date(2008, 2, 29) I concur. Trying to shoehorn month arithmetic into timedelta is a PITA, precisely because it's somewhat inexact. It's better to have some separate behavior that has well-defined behavior in edge cases. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
On Thu, Apr 16, 2009 at 12:10:36PM +0400, Oleg Broytmann wrote: This patch adds a monthdelta class and a monthmod function to the datetime module. The monthdelta class is much like the existing timedelta class, except that it represents months offset from a date, rather than an exact period offset from a date. I'd rather see the code merged with timedelta: timedelta(months=n). Unfortunately, that's simply impossible. A timedelta is a fixed number of seconds, and the time between one month and the next varies. I am very much in favour of there being the ability to add months to dates though. Obviously there is the question of what to do when you move forward 1 month from the 31st January; in my opinion an optional argument to specify different behaviours would be nice. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
2009/4/16 Jess Austin jess.aus...@gmail.com: I'm new to python core development, and I've been advised to write to python-dev concerning a feature/patch I've placed at http://bugs.python.org/issue5434, with Rietveld at http://codereview.appspot.com/25079. This patch adds a monthdelta class and a monthmod function to the datetime module. The monthdelta class is much like the existing timedelta class, except that it represents months offset from a date, rather than an exact period offset from a date. This allows us to easily say, e.g. 3 months from now without worrying about the number of days in the intervening months. date(2008, 1, 30) + monthdelta(1) datetime.date(2008, 2, 29) date(2008, 1, 30) + monthdelta(2) datetime.date(2008, 3, 30) The monthmod function, named in (imperfect) analogy to divmod, allows us to round-trip by returning the interim between two dates represented as a (monthdelta, timedelta) tuple: monthmod(date(2008, 1, 14), date(2009, 4, 2)) (datetime.monthdelta(14), datetime.timedelta(19)) Invariant: dt + monthmod(dt, dt+td)[0] + monthmod(dt, dt+td)[1] == dt + td I like the idea in principle. In practice, of course, month calculations are inherently ill-defined, so you need to be very specific in documenting all of the edge cases, and you should have strong use cases to ensure that the behaviour implemented matches user requirements. (I haven't yet had time to read the patch - you may well already have these points covered, certainly your comments above indicate that you appreciate the subtleties involved). These also work with datetimes! There are more details in the documentation included in the patch. In addition to the C module file, I've updated the datetime CAPI, the documentation, and tests. I feel this would be a good addition to core python. In my work, I've often ended up writing annoying one-off add-a-month or similar functions. I think since months work differently than most other time periods, a new object is justified rather than trying to shoe-horn something like this into timedelta. I also think that the round-trip functionality provided by monthmod is important to ensure that monthdeltas are first-class objects. I agree that ultimately it would be useful in the core. However, I'd suggest that you release the functionality as an independent module in the first instance, to establish it outside of the core. Once it has matured somewhat as a 3rd party module, it would then be ready for integration in the core. This also has the benefit that it makes the functionality available to users of Python 2.6 (and possibly earlier) rather than just in 2.7/3.1 onwards. Please let me know what you think of the idea and/or its execution. I hope the above comments help. Ultimately, I'd like to see this added to the core. It's tricky enough that having a standard implementation is a definite benefit in itself. But equally, I'd give it time to iron out the corner cases on a faster development cycle than the core offers before freezing it as part of the stdlib. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
2009/4/16 s...@pobox.com: date(2008, 1, 30) + monthdelta(1) datetime.date(2008, 2, 29) What would this loop would print? for d in range(1, 32): print date(2008, 1, d) + monthdelta(1) I have this funny feeling that arithmetic using monthdelta wouldn't always be intuitive. Oh, certainly! But in the absence of intuitive, I've found in the past that standardised is often better than nothing :-) (For example, I use Oracle's add_months function fairly often - it's not perfect, and not always intuitive, but at least it's well-defined in the corner cases, and fine for normal use). Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
Paul Moore p.f.moore at gmail.com writes: Oh, certainly! But in the absence of intuitive, I've found in the past that standardised is often better than nothing (For example, I use Oracle's add_months function fairly often - it's not perfect, and not always intuitive, but at least it's well-defined in the corner cases, and fine for normal use). I think something like date.add_months() would be better than the proposed monthdelta. The monthdelta proposal suggests that addition is something well-defined and rigourous, which is not really the case here (for example, if you add a monthdelta and then substract it again, I'm not sure you always get back the original date). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
In article b8ad139e0904152318p5473cbe5yb5f55a19894cc...@mail.gmail.com, Jess Austin jess.aus...@gmail.com wrote: I'm new to python core development, and I've been advised to write to python-dev concerning a feature/patch I've placed at http://bugs.python.org/issue5434, with Rietveld at http://codereview.appspot.com/25079. Without having looked at the code, I wonder whether you've looked at python-dateutil. I believe its relativedelta type does what you propose, plus much more, and it has the advantage of being widely used and tested. http://labix.org/python-dateutil -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
On Thu, Apr 16, 2009 at 3:45 AM, s...@pobox.com wrote: date(2008, 1, 30) + monthdelta(1) datetime.date(2008, 2, 29) What would this loop would print? for d in range(1, 32): print date(2008, 1, d) + monthdelta(1) for d in range(1, 32): ... print(date(2008, 1, d) + monthdelta(1)) ... 2008-02-01 2008-02-02 2008-02-03 2008-02-04 2008-02-05 2008-02-06 2008-02-07 2008-02-08 2008-02-09 2008-02-10 2008-02-11 2008-02-12 2008-02-13 2008-02-14 2008-02-15 2008-02-16 2008-02-17 2008-02-18 2008-02-19 2008-02-20 2008-02-21 2008-02-22 2008-02-23 2008-02-24 2008-02-25 2008-02-26 2008-02-27 2008-02-28 2008-02-29 2008-02-29 2008-02-29 I have this funny feeling that arithmetic using monthdelta wouldn't always be intuitive. I think that's true, especially since these calculations are not necessarily invertible: date(2008, 1, 30) + monthdelta(1) datetime.date(2008, 2, 29) date(2008, 2, 29) - monthdelta(1) datetime.date(2008, 1, 29) It could be that non-intuitivity is inherent in the problem of dealing with dates and months. I've aimed for a good compromise between the needs of the problem and the pythonic example of timedelta. I would submit that timedelta itself isn't intuitive at first blush, especially if one was weaned on the arcana of RDBMS date functions, but after one uses timedelta for just a bit it makes total sense. I hope the same may be said of monthdelta. cheers, Jess ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
2009/4/16 Antoine Pitrou solip...@pitrou.net: Paul Moore p.f.moore at gmail.com writes: Oh, certainly! But in the absence of intuitive, I've found in the past that standardised is often better than nothing (For example, I use Oracle's add_months function fairly often - it's not perfect, and not always intuitive, but at least it's well-defined in the corner cases, and fine for normal use). I think something like date.add_months() would be better than the proposed monthdelta. The monthdelta proposal suggests that addition is something well-defined and rigourous, which is not really the case here (for example, if you add a monthdelta and then substract it again, I'm not sure you always get back the original date). I didn't particularly get that impression, but I understand what you're saying. Personally, I don't think it matters much one way or the other. But as well as monthdelta, the proposal included monthmod. I'm not entirely happy with the name, but I like the idea - and particularly the invariant dt + monthmod(dt, dt+td)[0] + monthmod(dt, dt+td)[1] == dt + td. For me, that makes it a lot easier to reason about month increments. One thing I have certainly needed in the past is a robust way of converting a difference between two dates into natural language - 3 years, 2 months, 1 week and 5 days (or whatever). For that type of application, monthmod would have been invaluable. In my view, monthdelta seems a lot more natural alongside monthmod, than an add_months method would. And as monthmod is a function of two dates, it can't really be a method (OK, I know, something horrid like date1.monthdiff(date2) is possible, but honestly, I don't see that as reasonable). But this type of API design discussion does emphasise why I think the module should be a 3rd party package for a while before going into the stdlib. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
On Thu, Apr 16, 2009 at 5:16 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote: On Thu, Apr 16, 2009 at 11:54, Amaury Forgeot d'Arc amaur...@gmail.com wrote: In my opinion: arithmetic with months is a mess. There is no such month interval or year interval with a precise definition. If we adopt some kind of month manipulation, it should be a function or a method, like you would do for features like last_day_of_month(d), or following_weekday(d, 'monday'). date(2008, 1, 30).add_months(1) == date(2008, 2, 29) I concur. Trying to shoehorn month arithmetic into timedelta is a PITA, precisely because it's somewhat inexact. It's better to have some separate behavior that has well-defined behavior in edge cases. This is my experience also, and including a distinct and well-defined behavior in the core is exactly my intention with this patch. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
Thanks for everyone's comments! On Thu, Apr 16, 2009 at 9:54 AM, Paul Moore p.f.mo...@gmail.com wrote: I like the idea in principle. In practice, of course, month calculations are inherently ill-defined, so you need to be very specific in documenting all of the edge cases, and you should have strong use cases to ensure that the behaviour implemented matches user requirements. (I haven't yet had time to read the patch - you may well already have these points covered, certainly your comments above indicate that you appreciate the subtleties involved). I agree that ultimately it would be useful in the core. However, I'd suggest that you release the functionality as an independent module in the first instance, to establish it outside of the core. Once it has matured somewhat as a 3rd party module, it would then be ready for integration in the core. This also has the benefit that it makes the functionality available to users of Python 2.6 (and possibly earlier) rather than just in 2.7/3.1 onwards. I have uploaded a python-coded version of this functionality to the bug page. I should backport it through 2.3 and post that to pypi, but I haven't done that yet. The current effort was focused on the C module since that's how the rest of datetime is implemented, and also I wanted to learn a bit about CPython internals. To the latter point, I would _really_ appreciate it if someone could leave a few comments on Rietveld. Please let me know what you think of the idea and/or its execution. I hope the above comments help. Ultimately, I'd like to see this added to the core. It's tricky enough that having a standard implementation is a definite benefit in itself. But equally, I'd give it time to iron out the corner cases on a faster development cycle than the core offers before freezing it as part of the stdlib. I understand these concerns. I think I was too brief in my initial message. Here are the docstrings: print(monthdelta.__doc__) Months offset from a date or datetime. monthdeltas allow date calculation without regard to the different lengths of different months. A monthdelta value added to a date produces another date that has the same day-of-the-month, regardless of the lengths of the intervening months. If the resulting date is in too short a month, the last day in that month will result: date(2008,1,30) + monthdelta(1) - date(2008,2,29) monthdeltas may be added, subtracted, multiplied, and floor-divided similarly to timedeltas. They may not be added to timedeltas directly, as both classes are intended to be used directly with dates and datetimes. Only ints may be passed to the constructor, the default argument of which is 1 (one). monthdeltas are immutable. NOTE: in calculations involving the 29th, 30th, and 31st days of the month, monthdeltas are not necessarily invertible [i.e., the result above would NOT imply that date(2008,2,29) - monthdelta(1) - date(2008,1,30)]. print(monthmod.__doc__) monthmod(start, end) - (monthdelta, timedelta) Distribute the interim between start and end dates into monthdelta and timedelta portions. If and only if start is after end, returned monthdelta will be negative. Returned timedelta is never negative, and is always smaller than the month in which end occurs. Invariant: dt + monthmod(dt, dt+td)[0] + monthmod(dt, dt+td)[1] = dt + td There is better-looking documentation in html/library/datetime.html and html/c-api/datetime.html in the patch. By all means, if you're curious, download the patch and try it out yourself! cheers, Jess ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
On 16 Apr 2009, at 11:42, Paul Moore wrote: The key thing missing (I believe) from dateutil is any equivalent of monthmod. I agree with that. It's well-defined and it makes a lot of sense. +1 But, I dont think monthdelta can be made to work... what should the following be? print(date(2008,1,30) + monthdelta(1)) print(date(2008,1,30) + monthdelta(2)) print(date(2008,1,30) + monthdelta(1) + monthdelta(1)) Jared ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
On 2009-04-16 13:42, Paul Moore wrote: 2009/4/16 Ned Deilyn...@acm.org: In article b8ad139e0904152318p5473cbe5yb5f55a19894cc...@mail.gmail.com, Jess Austinjess.aus...@gmail.com wrote: I'm new to python core development, and I've been advised to write to python-dev concerning a feature/patch I've placed at http://bugs.python.org/issue5434, with Rietveld at http://codereview.appspot.com/25079. Without having looked at the code, I wonder whether you've looked at python-dateutil. I believe its relativedelta type does what you propose, plus much more, and it has the advantage of being widely used and tested. The key thing missing (I believe) from dateutil is any equivalent of monthmod. Hmm, it might be possible via relativedelta(d1,d2), but it's not clear to me from the documentation precisely what attributes/methods of a relativedelta object are valid for getting data *out* of it. I thought the examples were quite clear. relativedelta() has an alternate constructor precisely suited to these calculations but is general and handles more than just months. from dateutil.relativedelta import * dt = relativedelta(months=1) dt relativedelta(months=+1) from datetime import datetime datetime(2009, 1, 15) + dt datetime.datetime(2009, 2, 15, 0, 0) datetime(2009, 1, 31) + dt datetime.datetime(2009, 2, 28, 0, 0) dt.months 1 datetime(2009, 1, 31) + relativedelta(years=-1) datetime.datetime(2008, 1, 31, 0, 0) -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
Jon Ribbens jon+python-...@unequivocal.co.uk wrote: On Thu, Apr 16, 2009 at 12:10:36PM +0400, Oleg Broytmann wrote: This patch adds a monthdelta class and a monthmod function to the datetime module. The monthdelta class is much like the existing timedelta class, except that it represents months offset from a date, rather than an exact period offset from a date. I'd rather see the code merged with timedelta: timedelta(months=n). Unfortunately, that's simply impossible. A timedelta is a fixed number of seconds, and the time between one month and the next varies. I agree. I am very much in favour of there being the ability to add months to dates though. Obviously there is the question of what to do when you move forward 1 month from the 31st January; in my opinion an optional argument to specify different behaviours would be nice. Others have suggested raising an exception when a month calculation lands on an invalid date. Python already has that; it's spelled like this: dt = date(2008, 1, 31) dt.replace(month=dt.month + 1) Traceback (most recent call last): File stdin, line 1, in module ValueError: day is out of range for month What other behavior options besides last-valid-day-of-the-month would you like to see? cheers, Jess ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
Jess Austin jess.austin at gmail.com writes: What other behavior options besides last-valid-day-of-the-month would you like to see? IMHO, the question is rather what the use case is for the behaviour you are proposing. In which kind of situation is it acceptable to turn 31/2 silently into 29/2? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
Jess Austin wrote: What other behavior options besides last-valid-day-of-the-month would you like to see? - Add 30 days to the source date. I'm sure there are others. Followups to python-ideas. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
2009/4/16 Robert Kern robert.k...@gmail.com: On 2009-04-16 13:42, Paul Moore wrote: 2009/4/16 Ned Deilyn...@acm.org: In article b8ad139e0904152318p5473cbe5yb5f55a19894cc...@mail.gmail.com, Jess Austinjess.aus...@gmail.com wrote: I'm new to python core development, and I've been advised to write to python-dev concerning a feature/patch I've placed at http://bugs.python.org/issue5434, with Rietveld at http://codereview.appspot.com/25079. Without having looked at the code, I wonder whether you've looked at python-dateutil. I believe its relativedelta type does what you propose, plus much more, and it has the advantage of being widely used and tested. The key thing missing (I believe) from dateutil is any equivalent of monthmod. Hmm, it might be possible via relativedelta(d1,d2), but it's not clear to me from the documentation precisely what attributes/methods of a relativedelta object are valid for getting data *out* of it. I thought the examples were quite clear. relativedelta() has an alternate constructor precisely suited to these calculations but is general and handles more than just months. from dateutil.relativedelta import * dt = relativedelta(months=1) dt relativedelta(months=+1) from datetime import datetime datetime(2009, 1, 15) + dt datetime.datetime(2009, 2, 15, 0, 0) datetime(2009, 1, 31) + dt datetime.datetime(2009, 2, 28, 0, 0) dt.months 1 datetime(2009, 1, 31) + relativedelta(years=-1) datetime.datetime(2008, 1, 31, 0, 0) Yes, but given r = relativedelta(d1, d2) how do I determine the number of months between d1 and d2, and the remainder - what monthmod gives me. From the code, r.months looks like it works, but it's not documented, and I'm not 100% sure if it's always computed. The use case I'm thinking of is converting the difference between 2 dates into 3 years, 2 months, 5 days or whatever. I've got an application which needs to get this right for one of the dates being 29th Feb, so I *really* get to exercise the corner cases :-) Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
On 2009-04-16 17:17, Paul Moore wrote: 2009/4/16 Robert Kernrobert.k...@gmail.com: from dateutil.relativedelta import * dt = relativedelta(months=1) dt relativedelta(months=+1) from datetime import datetime datetime(2009, 1, 15) + dt datetime.datetime(2009, 2, 15, 0, 0) datetime(2009, 1, 31) + dt datetime.datetime(2009, 2, 28, 0, 0) dt.months 1 datetime(2009, 1, 31) + relativedelta(years=-1) datetime.datetime(2008, 1, 31, 0, 0) Yes, but given r = relativedelta(d1, d2) how do I determine the number of months between d1 and d2, and the remainder - what monthmod gives me. Oops! Sorry, I read too quickly and misread monthmod as monthdelta. From the code, r.months looks like it works, but it's not documented, and I'm not 100% sure if it's always computed. The result of relativedelta(d1, d2) is the same thing as if it were explicitly constructed from the years=, months=, etc. keyword arguments. From this example, I think this is something that can be relied upon: It works with dates too. relativedelta(TODAY, johnbirthday) relativedelta(years=+25, months=+5, days=+11, hours=+12) The use case I'm thinking of is converting the difference between 2 dates into 3 years, 2 months, 5 days or whatever. I've got an application which needs to get this right for one of the dates being 29th Feb, so I *really* get to exercise the corner cases :-) I believe relativedelta() is intended for this use case although it may resolve ambiguities in a different way than you were hoping. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
Antoine Pitrou solip...@pitrou.net wrote:
Jess Austin jess.austin at gmail.com writes:
What other behavior options besides last-valid-day-of-the-month
would you like to see?
IMHO, the question is rather what the use case is for the behaviour you are
proposing. In which kind of situation is it acceptable to turn 31/2 silently
into 29/2?
I have worked in utility/telecom billing, and needed to examine large
numbers of invoice dates, fulfillment dates, disconnection dates,
payment dates, collection event dates, etc. There would often be
particular rules for the relationships among these dates, and since
many companies generate invoices every day of the month, you couldn't
rely on rules like this always happens on the 5th. Here is an
example (modified) from the doc page. We want to find missing
invoices:
invoices = {123: [date(2008, 1, 31),
... date(2008, 2, 29),
... date(2008, 3, 31),
... date(2008, 4, 30),
... date(2008, 5, 31),
... date(2008, 6, 30),
... date(2008, 7, 31),
... date(2008, 12, 31)],
... 456: [date(2008, 1, 1),
... date(2008, 5, 1),
... date(2008, 6, 1),
... date(2008, 7, 1),
... date(2008, 8, 1),
... date(2008, 11, 1),
... date(2008, 12, 1)]}
for account, dates in invoices.items():
... a = dates[0]
... for b in dates[1:]:
... if b - monthdelta(1) a:
... print('account', account, 'missing between', a, 'and', b)
... a = b
...
account 456 missing between 2008-01-01 and 2008-05-01
account 456 missing between 2008-08-01 and 2008-11-01
account 123 missing between 2008-07-31 and 2008-12-31
In general, sometimes we care more about the number of months that
separate dates than we do about the exact dates themselves. This is
perhaps not the most common situation for date calculations, but it
does come up for some of us. I tired of writing one-off solutions
that would fail in unexpected corner cases, so I created this patch.
Paul Moore has also described his favorite use-case for this
functionality.
cheers,
Jess
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
On Apr 16, 2009, at 5:47 PM, Antoine Pitrou wrote: IMHO, the question is rather what the use case is for the behaviour you are proposing. In which kind of situation is it acceptable to turn 31/2 silently into 29/2? Essentially any situation in which you'd actually want a next month operation it's acceptable to do that. It's a human-interface operation, and as such, everyone (ahem) knows what it means to say 2 months from now, but the details don't usually have to be thought about too much. Of course when you have a computer program, you actually need to tell it what you really mean. I do a fair amount of date calculating, and use two different kinds of add-month: Option 1) Add n to the month number, truncate day number to fit the month you end up in. Option 2) As above, but with the additional caveat that if the original date is the last day of its month, the new day should also be the last day of the new month. That is: April 30th + 1 month = May 31st, instead of May 30th. They're both useful behaviors, in different circumstances. James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
I have this funny feeling that arithmetic using monthdelta wouldn't always be intuitive. Jess I think that's true, especially since these calculations are not Jess necessarily invertible: date(2008, 1, 30) + monthdelta(1) datetime.date(2008, 2, 29) date(2008, 2, 29) - monthdelta(1) datetime.date(2008, 1, 29) Jess It could be that non-intuitivity is inherent in the problem of Jess dealing with dates and months. To which I would respond: import this The Zen of Python, by Tim Peters ... In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. ... From the discussion I've seen so far, it's not clear that there is one obvious way to do it, and the ambiguity of the problem forces people to guess. My recommendations after letting it roll around in the back of my brain for the day: * I think it would be best to leave the definition of monthdelta up to individual users. That is, add nothing to the datetime module and let them write a function which does what they want it to do. * The idea/implementation probably needs to bake on the python-ideas list and perhaps comp.lang.python for a bit to see if some concensus can be reached on reasonable functionality. (I'm a bit behind on this thread. Hopefully someone else has already suggested these two things.) Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
My thoughts on balance regarding monthdeltas: -- Month operations are useful, people will want to do them -- I think having a monthdelta object rather than a method makes sense to me -- I think the documentation is severely underdone. The functionality is not intuitive and therefore the docs need a lot more detail than usual -- Can you specify 1 month plus 10 days?, i.e. add a monthdelta to a timedelta? -- What about other cyclical periods (fortnights, 28 days, lunar cycles, high tides)? Cheers, -T ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
On Thu, Apr 16, 2009 at 7:18 PM, s...@pobox.com wrote: I have this funny feeling that arithmetic using monthdelta wouldn't always be intuitive. Jess I think that's true, especially since these calculations are not Jess necessarily invertible: date(2008, 1, 30) + monthdelta(1) datetime.date(2008, 2, 29) date(2008, 2, 29) - monthdelta(1) datetime.date(2008, 1, 29) Jess It could be that non-intuitivity is inherent in the problem of Jess dealing with dates and months. To which I would respond: import this The Zen of Python, by Tim Peters ... In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. ... From the discussion I've seen so far, it's not clear that there is one obvious way to do it, and the ambiguity of the problem forces people to guess. My recommendations after letting it roll around in the back of my brain for the day: * I think it would be best to leave the definition of monthdelta up to individual users. That is, add nothing to the datetime module and let them write a function which does what they want it to do. * The idea/implementation probably needs to bake on the python-ideas list and perhaps comp.lang.python for a bit to see if some concensus can be reached on reasonable functionality. So far, all the other solutions to the problem that have been mentioned are easily supported in current python. Raise an exception when a calculation results in an invalid date: dt = date(2008, 1, 31) dt.replace(month=dt.month + 1) Traceback (most recent call last): File stdin, line 1, in module ValueError: day is out of range for month Add exactly 30 days to a date: dt + timedelta(30) datetime.date(2008, 3, 1) These operations are useful in particular contexts. What I've submitted is also useful, and currently isn't easy in core, batteries-included python. While I would consider the foregoing interpretation of the Zen to be backwards (this doesn't add another way to do something that's already possible, it makes possible something that currently encourages one to pull her hair out), I suppose it doesn't matter. If adding a class and a function to a module will require extended advocacy on -ideas and c.l.p, I'm probably not the person for the job. If, on the other hand, one of the committers wants to toss this in at some point, whether now or 3 versions down the road, the patch is up at bugs.python.org (and I'm happy to make any suggested modifications). I'm glad to have written this; I learned a bit about CPython internals and scraped a layer of rust off my C skills. I will go ahead and backport the python-coded version to 2.3. I'll continue this conversation with whomever for however long, but I suspect this topic will soon have worn out its welcome on python-dev. cheers, Jess ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
On Fri, 17 Apr 2009 07:41:19 am Jess Austin wrote: Others have suggested raising an exception when a month calculation lands on an invalid date. Python already has that; it's spelled like this: dt = date(2008, 1, 31) dt.replace(month=dt.month + 1) Traceback (most recent call last): File stdin, line 1, in module ValueError: day is out of range for month What other behavior options besides last-valid-day-of-the-month would you like to see? Adding one month to 31st January could mean: 1: raise an exception 2: return 28th February (last day of February) 3: return 3rd April (1 month = 31 days) 4: return 2nd April (1 month = 30 days) 5: return 28th February (1 month = 4 weeks = 28 days) 6: next business day after any of the above dates I don't really expect Python to support scenario 6, as that would require knowledge of local public holidays and conventions for week ends and working days. Open Office spreadsheet includes the following relevant functions: EDATE(start date; months) returns the serial number of the date that is a specified number of months before or after the start date. EOMONTH(start date; months) returns the serial number of the last day of the month that comes a certain number of months before or after the start date. MONTHS(start date; end date; type) calculate the difference in months between start and end date, possible values for type include 0 (interval) and 1 (in calendar months). Rather than a series of almost-identical functions catering for people who want 28 day months and 31 day months, I propose a keyword argument days_in_month which specifies the number of days in a month. Any positive integer should be accepted, but of course only 28, 30 and 31 will be meaningful for the common English meaning of the word month. 0 or None (the default) should trigger last day of the month behaviour (scenario 2 above). That will (I think) simplify both documentation and implementation. Adding 1 month to a day will be defined as adding days_in_month days (if given), and if not given, adding 31 days but truncating the result to the last day of the next month. Thoughts? -- Steven D'Aprano ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
On Fri, 17 Apr 2009 12:29:11 pm Steven D'Aprano wrote: Adding one month to 31st January could mean: 1: raise an exception 2: return 28th February (last day of February) 3: return 3rd April (1 month = 31 days) 4: return 2nd April (1 month = 30 days) 5: return 28th February (1 month = 4 weeks = 28 days) Obviously I meant March, not April. Oops. -- Steven D'Aprano ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
On 16 Apr, 11:11 pm, f...@fuhm.net wrote: On Apr 16, 2009, at 5:47 PM, Antoine Pitrou wrote: It's a human-interface operation, and as such, everyone (ahem) knows what it means to say 2 months from now, but the details don't usually have to be thought about too much. Of course when you have a computer program, you actually need to tell it what you really mean. I do a fair amount of date calculating, and use two different kinds of add-month: Option 1) Add n to the month number, truncate day number to fit the month you end up in. Option 2) As above, but with the additional caveat that if the original date is the last day of its month, the new day should also be the last day of the new month. That is: April 30th + 1 month = May 31st, instead of May 30th. They're both useful behaviors, in different circumstances. I don't have a third option, but something that would be useful to mention in the documentation for monthdelta: frequently users will want a recurring monthly event. It's important to note that you need to keep your original date around if you want these rules to be consistently applied. For example, if you have a monthly billing cycle that starts on May 31, you need to keep the original May 31 around to add monthdelta(X) if you want it to be May 31 when it rolls around next year; otherwise every time February rolls around all of your end-of- month dates get clamped to the 28th of every month. (Unless you're following James's option 2, of course, in which case things which are normally on the 28th will get clamped to the 31st of following months.) My experience with month-calculating software suggests that this is something very easy to screw up. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
On Fri, 17 Apr 2009 07:47:14 am Antoine Pitrou wrote: Jess Austin jess.austin at gmail.com writes: What other behavior options besides last-valid-day-of-the-month would you like to see? IMHO, the question is rather what the use case is for the behaviour you are proposing. In which kind of situation is it acceptable to turn 31/2 silently into 29/2? Any time the user expects one month from the last day of January to mean the last day of February. I dare say that if you did a poll of non-programmers, that would be a very common expectation, possibly the most common. I just asked the missus, who is a non-programmer, what date is one month after 31st January and her answer was 2rd of March on leap years, otherwise 3rd of March. -- Steven D'Aprano ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
Jess If, on the other hand, one of the committers wants to toss this in Jess at some point, whether now or 3 versions down the road, the patch Jess is up at bugs.python.org (and I'm happy to make any suggested Jess modifications). Again, I think it needs to bake a bit. I understand the desire and need for doing date arithmetic with months. Python is mature enough though that I don't think you can just toss this in. It should be available as a module outside of Python so people can beat on it, flush out bugs, make suggestions for enhancements, whatever. I believe you mentioned putting it up on PyPI. I think that's an excellent idea. I've used parts of Gustavo Niemeyer's dateutil package for a couple years and love it. It's widely used. Adding it to dateutil seems like another possibility. That would guarantee an instant user base. From there, if it is found to be useful it could make the leap to be part of the datetime module. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue5434: datetime.monthdelta
Steven D'Aprano wrote: 2rd of March on leap years, ^^^ The turd of March? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
