[Python-Dev] datetime nanosecond support

[Guido van Rossum]

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