[Python-Dev] datetime nanosecond support

Nick Coghlan ncoghlan at gmail.com
Wed Jul 25 14:11:13 CEST 2012


On Wed, Jul 25, 2012 at 7:24 PM, Christian Heimes <lists at cheimes.de> wrote:
> Am 25.07.2012 03:46, schrieb Guido van Rossum:
> I'd vote for two separate numbers, the first similar to JDN (Julian Day
> Number [1]), the second for nanoseconds per day. 3600 * 1000000 fit
> nicely into an unsigned 32bit int. This approach has the neat benefit
> that we'd get rid of the timestamp_t limitations and year 2038 bug at
> once. IIRC datetime used to break for dates before 1970 on some system
> because timestamp_t was unsigned. Python could finally support dates BC!

Alternatively, use Decimal as the internal representation (backed by
cdecimal if additional speed is needed).

However, rather than getting buried in the weeds right here:

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).

2. I don't think the stdlib is the right place to define the initial
version of this. It seems most sensible to first fork the pure Python
version of datetime, figure out the details to get that working as a
new distribution on PyPI, and then fork the C implementation to make
the PyPI version faster. Assuming it can be completed in time, the
revised API could then be brought back as a PEP (alternatively,
depending on the details of the proposal, the use case may be deemed
sufficiently rare that it is just kept as a specialist module on
PyPI).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list