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. I'm not sure this thread / discussion has reached critical mass yet, meanwhile I was looking at what was involved and came up with this half-baked patch - by no way meant to be complete or correct, but rather get a feel to it. I can't help thinking this is much more involved than I first expected, and what I try to achieve should be reasonably simple. Stepping back a little, I wonder if the datetime module is really the right location, that has constructor(year, month, day, ..., second, microsecond) - with 0<ms<999999, no millis. adding 0<ns<999 would seem quite ugly, in fact nothing looks quite right. datetime seems to be dealing with 'calendar time' stuff - and to some extent, maybe, shouldn't concern itself so much with fraction of seconds. I'm pondering now if the 'time' module that seems to be dealing with 'computer clock time' wouldn't be a better target to introduce struct_timespec and the like. I'd be curious to hear back from this list, if this deserves more investigation or what might be a better way to go. Regards, Matthieu On 12/11/2014 11:46 AM, Antoine Pitrou wrote: > On Thu, 11 Dec 2014 13:43:05 -0600 > Skip Montanaro <skip.montanaro at gmail.com> wrote: >> On Thu, Dec 11, 2014 at 1:23 PM, Antoine Pitrou <solipsis at pitrou.net> wrote: >>> I think strftime / strptime support is a low-priority concern on this >>> topic, and can probably be discussed independently of the core >>> nanosecond support. >> >> Might be low-priority, but with %f support as a template, supporting >> something to specify nanoseconds should be pretty trivial. The hardest >> question will be to convince ourselves that we aren't choosing a >> format code which some other strftime/strptime implementation is >> already using. >> >> In addition, ISTR that one of the use cases was analysis of datetime >> data generated by other applications which has nanosecond resolution. > > One of the use cases is to deal with OS-generated timestamps without > losing information. As long as you don't need to represent or parse > those timestamps, strptime / strftime don't come into the picture. > > Regards > > Antoine. > _______________________________________________ > Python-Dev mailing list > Python-Dev at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: datetime_ns.patch Type: text/x-patch Size: 39257 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20141216/d47be824/attachment.bin>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4