Aren't the wrappers for the kernel's time-related structs typically in the time module? That seems the place to start. Eventually we can support going between those structs and the datetype datatype (the latter may have to grow an option to specify nsec).

On Tue, Dec 16, 2014 at 11:21 AM, Matthieu Bec <> wrote:
yes that was mentioned in this thread, %nN looks quite reasonable.

still, I'd like to steer the conversation back to the other aspect - where should something like struct_timespec land in the first place, is datetime really the best to capture that?

Most of the conversation has been revolving around strftime/strptime.
That seems to validate Antoine's point in the first place.

Let's see what people say but maybe this thread should end to restart as separate topics?


On 12/16/14 11:08 AM, Skip Montanaro wrote:

On Tue, Dec 16, 2014 at 11:10 AM, matthieu bec <
<>> wrote:
 > Agreed with Antoine, strftime/strptime are somewhat different concerns.
 > Doesn't mean thay cannot be fixed at the same time but it's a bit a
 > separate.

Which reminds me... Somewhere else (maybe elsewhere in this thread?
maybe on a bug tracker issue?) someone mentioned that Ruby uses %N for
fractions of a second (and %L specifically for milliseconds). Here's the
bit from the Ruby strftime doc:

%L - Millisecond of the second (000..999)
%N - Fractional seconds digits, default is 9 digits (nanosecond)
           %3N  millisecond (3 digits)
           %6N  microsecond (6 digits)
           %9N  nanosecond (9 digits)
           %12N picosecond (12 digits)

There's no obvious reason I can see to reinvent this particular wheel,
at least the %N spoke. The only question might be whether to modify
Python's existing %f format to accept a precision (defaulting to 6), or
add %N in a manner similar (or identical) to Ruby's semantics.


Python-Dev mailing list

Matthieu Bec                GMTO Corp
cell : +1 626 425 7923      251 S Lake Ave, Suite 300
phone: +1 626 204 0527      Pasadena, CA 91101
Python-Dev mailing list

--Guido van Rossum (