
On 12/10/14 7:33 AM, Nick Coghlan 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
On 10 December 2014 at 16:31, Matthieu Bec <mdcb808@gmail.com> wrote: 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.