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? Regards, Matthieu On 12/16/14 11:08 AM, Skip Montanaro wrote:
On Tue, Dec 16, 2014 at 11:10 AM, matthieu bec <mbec@gmto.org <mailto:mbec@gmto.org>> 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.
Skip
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/mdcb808%40gmail.com
-- Matthieu Bec GMTO Corp cell : +1 626 425 7923 251 S Lake Ave, Suite 300 phone: +1 626 204 0527 Pasadena, CA 91101