On Wed, Jul 25, 2012 at 7:11 AM, Christian Heimes <li...@cheimes.de> wrote: > Am 25.07.2012 14:11, schrieb Nick Coghlan: >> 1. For the reasons presented, I think it's worth attempting to define >> a common API that is based on datetime, but is tailored towards high >> precision time operations (at least using a different internal >> representation, perhaps supporting TAI). > > This is a great opportunity to implement two requests at once. Some > people want high precision datetime objects while others would like to > see a datetime implementation that works with dates BC.
Beware, people requesting dates BC rarely know what they are asking for. (E.g. Jesus wasn't born on 12/25/0001.) The calendrical ambiguities are such that representing dates that far in the past is better left to a specialized class. Read the original discussions about the datetime type; it loses meaning for dates long ago even if it can represent them, but the choice was made to ignore these and to offer a uniform abstraction for 1 <= year <= 9999. TBH I'm more worried about years >= 10000. :-) >>>> from datetime import datetime, timedelta >>>> epoch = datetime.datetime(1970, 1, 1) >>>> epoc - timedelta(days=1969*365.242) > datetime.datetime(1, 1, 1, 12, 2, 52, 799998) >>>> epoch - timedelta(days=1970*365.242) > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > OverflowError: date value out of range > > >> 2. I don't think the stdlib is the right place to define the initial >> version of this. > > +1 +1 -- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
