thebjorn wrote: > John Machin wrote: > > thebjorn wrote: > > > John Machin wrote: > > > > thebjorn wrote: > [...] > > > > Holy code bloat, Batman! Try this: > > > > > > > > return now.year - born.year - (birthday > now) > > > > > > yuck :-) > > > > But this: > > return now.year - born.year - (birthday > now and 1 or 0) is not yuck??? > > Correct. > > > > [...] > > > > It's the irregular-size months that cause the problems. If you can work > > > > out the months difference, then just floor_div by 12 to get the years > > > > difference. > > > > > > I don't agree that the irregular sized months cause a problem in this > > > case. They do cause a problem if you're asking "when is today + one > > > month?", i.e. there isn't an unambiguous answer to that question in > > > general (e.g. if today was January 31). We're asking a different kind > > > of question though: "has it been at least one month since January 31?", > > > the answer would be no on Feb 29 and yes on Mar 1. > > > > If a bank were paying you interest on a monthly basis, and you > > deposited money on Jan 31 and pulled it out on the last day of > > February, that would count as one month. This is what I call the "today > > - yesterday == 1" rule. For computing things like duration of employee > > service, you need the "today - yesterday == 2" rule -- on the > > assumption that service counts from start of business yesterday to > > close of business today. So hire date of 1 Feb to fire date of (last > > day of Feb) would count as one month. > > You give a good argument that the concept of a month is fuzzy
Sorry, I can't imagine where you got "fuzzy" from. Perhaps you mean some other word. The concept is capable of being expressed precisely. > I still > don't believe that it makes the concept of a year fuzzy (or that the > fuzziness of month needs to be accounted for when computing years). The point is to ensure that (say) 24 months of employment and 2 years of employment are determined in a consistent fashion. > > > Sorry, I don't understand. Why are you speechless? What would I want to > > use the calendar module for? Apart from the leap() function and the > > table of days in a month, the calendar module doesn't have any of the > > functionality that one would expect in a general-purpose date class. > > Well, I thought replacing a 4 line function with 31 lines, 13 of which > duplicated functionality in the standard library was overkill. I think you missed the point that the lines I quoted were straight out of a self-contained library that existed (in C as well as Python) way before the datetime module was a gleam in Fred & the timbot's eyes. Even if I had noticed a leap year function in the calendar module, I would probably not have used it. The Python version of the module was just a stopgap while I fiddled with getting a C extension going. The C leap year function doesn't have any of that modulo stuff in it. > I came > up with this yesterday which seems sufficient? > > def yeardiff(a, b): > y = a.year - b.year > if (a.month, a.day) < (b.month, b.day): # tuple comparison > y -= 1 > return y At least it doesn't blow up when b is leapyear-02-29. It just gives the wrong answer when a is nonleapyear-02-28. E.g. it gives 0 years difference from 1992-02-29 to 1993-02-28 instead of 1. -- http://mail.python.org/mailman/listinfo/python-list