[Python-ideas] Date/time literals
masklinn at masklinn.net
Sun May 30 13:43:18 CEST 2010
On 2010-05-30, at 13:17 , Chris Rebert wrote:
> On Sun, May 30, 2010 at 4:06 AM, Marcos Bonci <marcos.bonci at 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 . 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 , though note that the inclusion in Java 7
>>> apparently isn't certain yet due to delays in the JSR 310 process .
>>> For a (probably long outdated) overview of what JSR 310 would provide,
>>> see 
>>>  http://joda-time.sourceforge.net/
>>>  http://jcp.org/en/jsr/detail?id=310
>>>  http://tech.puredanger.com/java7
>> 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
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)
More information about the Python-ideas