<div>From "[Python-Dev] PEP 564: Add new time functions with nanosecond resolution" (2017-10-16 hh:mm ss[...] -Z) </div><div><a href="https://groups.google.com/forum/m/#!topic/dev-python/lLJuW_asYa0">https://groups.google.com/forum/m/#!topic/dev-python/lLJuW_asYa0</a> :</div><div><br></div><div>> Maybe that's why we haven't found any CTCs (closed timelike curves) yet.</div><div>></div><div>> Aligning simulation data in context to other events may be enlightening: is there a good library for handing high precision time units in Python (and/or CFFI)?</div><div><br></div><div>There's not yet an ISO8601-like standard for this level of time/date precision.</div><div><br></div><div>Correlating particle events between experiments does require date+time.</div><br>On Monday, May 14, 2018, David Mertz <<a href="mailto:mertz@gnosis.cx">mertz@gnosis.cx</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Chris is certainly right. A program that deals with femtosecond intervals should almost surely start by defining a "start of experiment" epoch where microseconds are fine. Then within that epoch, events should be monotonic integers for when measured or calculated times are marked.</div><div dir="auto"><br></div><div dir="auto">I can easily see reasons why a specialized wrapped int for FemtosecondsFromStart could be useful. But that's still a specialized need for a third party library. One possible use of this class might be to interoperate with datetimes or timedeltas. Conceivably sick interoperability could be dealing with leap seconds when needed. But "experiment time" should be a simple monotonic and uniform counter.<br><br><div class="gmail_quote" dir="auto"><div dir="ltr">On Mon, May 14, 2018, 6:35 PM Chris Barker - NOAA Federal via Python-ideas <<a href="mailto:python-ideas@python.org" target="_blank">python-ideas@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">><br>
> UTC and leap seconds aren't a problem.<br>
<br>
Of course they are a problem— why else would they not be implemented<br>
in datetime?<br>
<br>
But my point if that given datetimestamp or calculation could be off<br>
by a second or so depending on whether and how leap seconds are<br>
implemented.<br>
<br>
It just doesn’t seem like a good idea to be handling months and<br>
femptoseconds with the same “encoding”<br>
<br>
-CHB<br>
______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" rel="noreferrer" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
</blockquote></div></div></div>
</blockquote>