mdcb added the comment:
In the confines of PTP / IEEE1588, it's actually quite common and can be
useful. It's not so much the ns, but the <1us that is missing.
--
___
Python tracker
<https://bugs.pytho
mdcb added the comment:
This brings me back some times. Sorry if I am not up to date, the issue as I
recall from back then was there wasn't even microseconds.
In telemetry, you can often have these kind time stamped measurements, it's not
insignificant noise nobody c
Changes by mdcb :
--
nosy: +mdcb...@gmail.com
___
Python tracker
<http://bugs.python.org/issue24511>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by mdcb :
--
nosy: +mdcb...@gmail.com
___
Python tracker
<http://bugs.python.org/issue24510>
___
___
Python-bugs-list mailing list
Unsubscribe:
mdcb added the comment:
Alexander,
The initial patch is indeed minimal. If it gains momentum and some level of
acceptation, I'd be happy to do more amends and fixes as needed and recommended.
As for 2.7.9 - I'm not sure it makes much sense going PyPI patch if it's not
going t
mdcb added the comment:
backward compatibility is implemented as 'new python can load old pickle'.
isn't it what backward compatible means?
The payload changed from 10 to 12 bytes to accomodate the nanoseconds, I don't
know how to handle reverse-backward compatibility or i
mdcb added the comment:
Intention of the patch was to keep it simple and limited to nanoseconds (per
the report).
Throwing in Decimal would work (and possibly bring further precision) but
consider:
datetime.fromnanoseconds(ns)
vs
datetime.fromtimestamp(Decimal(ts))
I find the former
mdcb added the comment:
minor bug fixes and improvements in new attachment.
--
Added file: http://bugs.python.org/file37512/datetime.nanosecond.patch
___
Python tracker
<http://bugs.python.org/issue15
Changes by mdcb :
___
Python tracker
<http://bugs.python.org/issue15443>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/pytho
mdcb added the comment:
patch in attachment is an attempt to provide the datetime type nanosecond
support, handles pickle versioning, expose a new class method
datetime.fromnanoseconds
--
keywords: +patch
nosy: +mdcb...@gmail.com
Added file: http://bugs.python.org/file37509
mdcb added the comment:
naively and coming from C, you have time_t to represent time so even though
underneath it's typedef, it gives the casual user like me comfort (2038 not
accounted). I don't know the details why struct timespec was chosen rather than
nanoseconds as integer, a
mdcb added the comment:
firefox did something and changed some fields I did not intend to. I'm trying
to undo that now.
--
resolution: -> rejected
status: open -> pending
___
Python tracker
<http://bugs.python.
mdcb added the comment:
I'm fine my patch doesn't resolve the "nanosecond support", but that doesn't
mean the issue is closed per say.
Ref. to PEP410 rejection and de facto standard seems a bit expeditive.
assuming it worked, this would somewhat be more agreeabl
mdcb added the comment:
can we change back the title because in fact, exposing struct timespec wasn't
really the intention (but keep the patch if you want it!)
--
___
Python tracker
<http://bugs.python.org/is
mdcb added the comment:
I'm going to be my own devil's advocate:
PyLong_FromLong
...
Thanks for all the links, I hadn't realized there was so much background to the
issue, there is some good reading there too.
you've changed the title now, but in fact the intention
Changes by mdcb :
--
hgrepos: -289
___
Python tracker
<http://bugs.python.org/issue23084>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
New submission from mdcb:
nanosecond support has been discussed at length on python-dev and issue 15443.
POSIX.1b defines a struct timespec that is commonly used in C, and seems a good
candidate to add core nanosecond support. kernel's time-related structs
typically end up in the time m
17 matches
Mail list logo
