<div dir="ltr"><div>Hi all,<br><br>I realize this is a bit of a pet peeve of me, since<br>in my day job I sometimes get people complaining that<br>numerical data is "off" in the sixteenth significant digit<br>(i.e. it was stored as a double).<br><br>I have a bunch of favorite comparisons to make this clear<br>how accurate a "double" really is: you can measure the<br>distance to Neptune down to a millimeter with it, or<br>the time from the extinction of the dinosaurs until<br>now down to half-second resolution.<br><br>Unfortunately for my argument, measuring time is one<br>of the most accurate physical measurements we can make,<br>and the best of the best exceed double-precision accuracy.<br><br>For example, the best atomic clock<br><a href="https://www.sciencealert.com/physicists-have-broken-the-record-for-the-most-accurate-clock-ever-built">https://www.sciencealert.com/physicists-have-broken-the-record-for-the-most-accurate-clock-ever-built</a><br>achieves a measurement uncertainty of 3e-18, which is about two order of<br>magnitudes more accurate than what double-precision gives you;<br>the latter runs out of steam at 2.2e-16.<br><br></div>So I realize there is obvious a strong need for (the illusion of)<br><div>such precise time keeping in the Python API <wink>.<br><br><div>Interestingly, that 2.2e-16 pretty much aligns with the accuracy of the<br></div><div>cesium atomic clocks which are currently used to *define* the second.<br></div><div>So we move to this new API, we should provide our own definition<br></div>of the second, since those rough SI seconds are just too imprecise for that.<br><br>Stephan<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-10-16 9:03 GMT+02:00 Stefan Krah <span dir="ltr"><<a href="mailto:stefan@bytereef.org" target="_blank">stefan@bytereef.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Oct 16, 2017 at 08:40:33AM +0200, Stephan Houben wrote:<br>
> "The problem is that Python returns time as a floatting point number<br>
> > which is usually a 64-bit binary floatting number (in the IEEE 754<br>
> > format). This type starts to loose nanoseconds after 104 days."<br>
> ><br>
> ><br>
> Do we realize that at this level of accuracy, relativistic time dilatation<br>
> due<br>
> to continental drift starts to matter?<br>
<br>
</span>tai64na has supported attoseconds for quite some time:<br>
<br>
    <a href="https://cr.yp.to/libtai/tai64.html" rel="noreferrer" target="_blank">https://cr.yp.to/libtai/tai64.<wbr>html</a><br>
<br>
The relativity issue is declared to be out of scope for the document. :-)<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Stefan Krah<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="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" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
</div></div></blockquote></div><br></div>