On 12/10/14 7:33 AM, Nick Coghlan wrote: > On 10 December 2014 at 16:31, Matthieu Bec <mdcb808 at gmail.com> wrote: >> newbie first post on this list, if what follows is of context ... >> >> Hi all, >> >> I'm struggling with issue per the subject, read different threads and issue >> http://bugs.python.org/issue15443 that started 2012 still opened as of >> today. >> >> Isn't there a legitimate case for nanosecond support? it's all over the >> place in 'struct timespec' and maybe wrongly I always found python and C >> were best neighbors. That's for the notional aspect. > If you skip down to the more recent 2014 part of the discussion, the > use case has been accepted as valid, but the idea still needs a > concrete change proposal that addresses the various API design and > backwards compatibility issues that arise. Specifically, questions > like: Thanks Nick. These are typically discussed on this list or using the bug tracker? maybe YNGTNI applied, not clear why it's not there after 2 eyars. I'm no expert but one could imagine something reasonably simple: - a new type datetime.struct_timespec (a la time.struct_tm) - a new constructor datetime.time(struct_timespec), so what already exists untouched - pickle versioning using free bits, the new format that favors clarity over saving byte (as described in 15443) - not sure what's at stake with the strp/ftime() but cant imagine it's a biggie Regards, Matthieu > * preserving compatibility with passing in microsecond values > * how to accept nanosecond values > * how to correctly unpickle old datetime pickle values > * how to update strptime() and strftime() > > Cheers, > Nick. >
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