Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Quick Python question



Jerry Feldman wrote:
> Basically, given a date, I need to add years to that date.

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, then
a timedelta will work, put in your duration--365 days, or 365 and a
quarter days, or something else...

>  One way to do
> it is:
>
> from datetime import date
> d = date.today() # initialize d to some date
> d = 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. 

If you want to increment the year field, then I think you are doing the
right thing.


> The above method certainly works fine except for February 29th, which is not important. 
>   

In that case the answer is ambiguous again.  I don't know what the right
answer is, I presume that there are canonical right answers for
different problem domains.  If you try to defiine "d = 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 February
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".)

Reminds me of another old story: Some old English great house was using
Sybase (I think) to catalogue their collection of stuff but Sybase
wouldn't offer a date type that went back nearly far enough.  The
problem was the switchover from Gregorian to Julian dates, it happened
at different times in different places, so the database refused to do
dates that were ambiguous and they had to roll their own for anything
that predated the Russian revolution.

Time seems simple, it comes in seconds and we know how big they are, but
once humans start counting up and converting to larger units and being
creative in how they do so, it is an unholy mess.  Ever listened to WWV
count out a 61-second minute?  Freaky.


-kb







BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org