[Python-Dev] datetime nanosecond support (original) (raw)

Guido van Rossum guido at python.org
Mon Jul 30 07:10:32 CEST 2012

It can't be that easy. DST never is... For one, the dst flag is two bits -- it can be on, off, or undefined. Also it should probably only apply when a tzinfo is present. I don't recall that pickling ever was the reason, but it could have been the size of the in-memory representation (for reasons I can't fully recall we were very concerned about the memory size of datetime objects). Anyway, I don't want to be the limiting factor here, and I think this (as well as nanoseconds) should be considered, but I don't want to have to hand-hold the design. A PEP is in order.

--Guido

On Mon, Jul 30, 2012 at 6:56 AM, Stuart Bishop <stuart at stuartbishop.net> wrote:

On Wed, Jul 25, 2012 at 9:11 PM, Christian Heimes <lists at 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. Back when the datetime library was being designed, a limiting factor was size of the pickle (for reasons that I think no longer apply). Support for the isdst flag was never in there, only because the extra single bit required overflowed the pickle size limit. If api changes are being considered, please consider adding this bit back to match the standard libraries. This will let me make the pytz timezone library's API saner, and allow Python to do wallclock datetime arithmetic without ambiguous cases. -- Stuart Bishop <stuart at stuartbishop.net> http://www.stuartbishop.net/

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list