Quick Python question

[gaf-mNDKBlG2WHs at public.gmane.org (Jerry Feldman)]

In the current model that I have, it is really a simple thing. In a more
complex model, where I generate cash flows every month on the last day
of the month or when I compute the middle of the period (let's say a
quarter) it gets more complicated. In our C++ code we have multiple
calendars, business day rules, etc, but I'm not planning on the Python
extension to be that complex. Meanwhile, I'll look into mxDateTime that
Adam posted earlier.
-- BTW I may have a fetish for accurate dates. Back in the early 70s I
wrote a complete date/time system in COBOL that compensated for y2K. I
also wrote all the Unix time functions for libc in PDP11 C. And I
erroneously got blamed for a failure of Tru64 Unix when a standards test
failed because of the 2038 problem. (Finnbarr Murphy got the X/Open
standards people to fix their broken test :-)

On 10/08/2009 12:52 PM, Kent Borg wrote:
> The obvious thing to do is use a timedelta object--except timedelta
> objects don't provide for "years".  The problem is that a "year" is
> ambiguous.  If the "year" you are interested in is a time duration, the=
n
> a timedelta will work, put in your duration--365 days, or 365 and a
> quarter days, or something else...
>
>  =20
>> >  One way to do
>> > it is:
>> >
>> > from datetime import date
>> > d =3D date.today() # initialize d to some date
>> > d =3D date(d.year + 1, d.month, d.day)
>> >
>> > In the above case I'm setting a date object d to todays date, then
>> > advancing it to the next year. Is there a more elegant or efficient =
way
>> > of doing this in Python.=20
>>    =20
> If you want to increment the year field, then I think you are doing the=

> right thing.
>
>
>  =20
>> > The above method certainly works fine except for February 29th, whic=
h is not important.=20
>> >  =20
>>    =20
> In that case the answer is ambiguous again.  I don't know what the righ=
t
> answer is, I presume that there are canonical right answers for
> different problem domains.  If you try to defiine "d =3D date(2009, 2,
> 29)" you will get "ValueError: day is out of range for month", and
> depending on what is your correct behavior, catch that error and fix
> there.  (I think it is probably wrong to initially special case Februar=
y
> 29th--let the system complain first and fix it then.  Verify the error
> was caused by something you understand and then fix it appropriately)
>
> Python cannot do the right thing for you for free because the answer is=

> ambiguous.  (MS Excel goes to great efforts to do the right thing for
> dates and times and occasionally wreaks havoc doing so, scientific
> studies have been ruined because Excel took neutral data and started
> formatting it "the right way".)
>
>  =20


--=20
Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846