<div dir="ltr">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).<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 16, 2014 at 11:21 AM, Matthieu Bec <span dir="ltr"><<a href="mailto:mbec@gmto.org" target="_blank">mbec@gmto.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">yes that was mentioned in this thread, %nN looks quite reasonable.<br>
<br>
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?<br>
<br>
Most of the conversation has been revolving around strftime/strptime.<br>
That seems to validate Antoine's point in the first place.<br>
<br>
Let's see what people say but maybe this thread should end to restart as separate topics?<br>
<br>
Regards,<br>
Matthieu<span class=""><br>
<br>
On 12/16/14 11:08 AM, Skip Montanaro wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
On Tue, Dec 16, 2014 at 11:10 AM, matthieu bec <<a href="mailto:mbec@gmto.org" target="_blank">mbec@gmto.org</a><br></span><div><div class="h5">
<mailto:<a href="mailto:mbec@gmto.org" target="_blank">mbec@gmto.org</a>>> wrote:<br>
 > Agreed with Antoine, strftime/strptime are somewhat different concerns.<br>
 > Doesn't mean thay cannot be fixed at the same time but it's a bit a<br>
 > separate.<br>
<br>
Which reminds me... Somewhere else (maybe elsewhere in this thread?<br>
maybe on a bug tracker issue?) someone mentioned that Ruby uses %N for<br>
fractions of a second (and %L specifically for milliseconds). Here's the<br>
bit from the Ruby strftime doc:<br>
<br>
%L - Millisecond of the second (000..999)<br>
%N - Fractional seconds digits, default is 9 digits (nanosecond)<br>
           %3N  millisecond (3 digits)<br>
           %6N  microsecond (6 digits)<br>
           %9N  nanosecond (9 digits)<br>
           %12N picosecond (12 digits)<br>
<br>
There's no obvious reason I can see to reinvent this particular wheel,<br>
at least the %N spoke. The only question might be whether to modify<br>
Python's existing %f format to accept a precision (defaulting to 6), or<br>
add %N in a manner similar (or identical) to Ruby's semantics.<br>
<br>
Skip<br>
<br>
<br></div></div><span class="">
______________________________<u></u>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/<u></u>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/mdcb808%40gmail.com" target="_blank">https://mail.python.org/<u></u>mailman/options/python-dev/<u></u>mdcb808%40gmail.com</a><br>
<br>
</span></blockquote><span class="">
<br>
-- <br>
Matthieu Bec                GMTO Corp<br>
cell : <a href="tel:%2B1%20626%20425%207923" value="+16264257923" target="_blank">+1 626 425 7923</a>      251 S Lake Ave, Suite 300<br>
phone: <a href="tel:%2B1%20626%20204%200527" value="+16262040527" target="_blank">+1 626 204 0527</a>      Pasadena, CA 91101<br>
______________________________<u></u>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/<u></u>mailman/listinfo/python-dev</a><br></span>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" target="_blank">https://mail.python.org/<u></u>mailman/options/python-dev/<u></u>guido%40python.org</a><br>
</blockquote></div><br clear="all"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</div>
</div>