On 2010-05-30, at 03:49 , Chris Rebert wrote:
On Sat, May 29, 2010 at 6:05 PM, Marcos Bonci <marcos.bonci@gmail.com> wrote:
Hi! I've been working a lot with date/time variables lately, and maybe it's just me, and maybe I just don't get it yet, but it sure doesn't feel like there's one-and-only-one elegant, obvious way to work with them. Feels like working with strings in C.
Reading the rest of your post, it sounds like you're unaware of the fairly nice API of the `datetime` std lib module: http://docs.python.org/library/datetime.html
IMO, it's pretty nice to work with; although it is annoying that some operations can only be done using the more primitive `time` or `calendar` modules. Patches are probably welcome; perhaps I should consider trying to write one.
datetime does have a bunch of issues and limitations which I believe soon become harmful when doing serious date/calendaring works (which I don't claim to do, but I've seen colleagues in serious trouble due to both personal lack of knowledge in the field and issues with datetime itself): it only supports a gregoriany calendar for instance, it's horrendous in dealing with timezones, some methods are pretty much broken, constructor refuses "24" as an hour value, blows up on positive leap seconds)… See the following resources for issues with datetime: http://blog.mfabrik.com/2008/06/30/relativity-of-time-shortcomings-in-python... http://www.enricozini.org/2009/debian/using-python-datetime/ Libraries built over datetime: http://labix.org/python-dateutil http://pytz.sourceforge.net/ [1] [1] note that as mentioned in the first blog post, datetime apparently has issues re querrying tz objects, so it's generally suggested to work with utc-only datetime objects and let the timezone stuff to direct pytz calls.