On 2010-05-30, at 13:17 , Chris Rebert wrote:
On Sun, May 30, 2010 at 4:06 AM, Marcos Bonci <marcos.bonci@gmail.com> wrote:
It's very nice of you to attribute such a great post to me, but I just linked to it. I'm not the author of any of the resources I linked to.
Oops, lack-of-sleep in action!.. Being myself an example of the inattentive guy I was talking about, I guess...
One of the issues from what I understand is that you pretty much need to be a specialist in the time/date domain (or have one available at all times) to get this stuff right. I'm guessing the Python community doesn't have any involved/available, least of which at the core level.
Furthermore if you want to see what's usually considered a best-of-breed in the java world, look not at the standard library but at joda time [1]. In fact, with Java 7 the current Date/Calendar API should be replaced by one strongly inspired by Joda (and created by its author) and influenced by a few other APIs of the Java world. See JSR 310 for details [2], though note that the inclusion in Java 7 apparently isn't certain yet due to delays in the JSR 310 process [3].
For a (probably long outdated) overview of what JSR 310 would provide, see [4]
[1] http://joda-time.sourceforge.net/ [2] http://jcp.org/en/jsr/detail?id=310 [3] http://tech.puredanger.com/java7 [4] http://today.java.net/pub/a/today/2008/09/18/jsr-310-new-java-date-time-api....
Since it's all open source stuff, shouldn't it be possible to just "clone" most of it? Or is there some Java-specific thing that makes it hard to translate?
Doubtful, but anyhow, I hear mxDateTime (http://www.egenix.com/products/python/mxBase/mxDateTime/ ) is the current and extant Python gold standard. Not quite as nimble as Joda (though not many applications need to deal with e.g. Coptic dates anyway), but still a significant improvement over `datetime`.
Used to be, but these days I believe most people use datetime + dateutil instead. mx.DateTime is actually an improvement of what came before datetime (raw date and time modules) and datetime was inspired by mx.DateTime. Most of the mx.DateTime stuff missing from datetime is in dateutil, and mx.DateTime is very heavyweight, a pain to install and has other issues. Mostly a complete lack of support in implementations other than CPython. A significant limitation of datetime which mx doesn't have, though, is that mx.DateTime can deal with BCE dates (< year 1). I'm sure M.A. Lemburg will disagree and fix the mistakes in my post if he passes by though. Anyway personally, my biggest issues with mx.DateTime are that it mandates the installation of the rest of the mx distro (the package is actually egenix-mx-base) and that it generally refuses to install, short of a bare `python setup.py install` (eqsy_install or pip install egenix-mx-base didn't ever work for me)