[Python-Dev] PEP 564: Add new time functions with nanosecond resolution
victor.stinner at gmail.com
Tue Oct 24 03:00:45 EDT 2017
Thanks Thomas, it was interesting! You confirmed that time.time_ns() and
other system clocks exposed by Python are inappropriate for sub-nanosecond
By the way, you mentionned that clocks are not synchronized. That's another
revelant point. Even if system clocks are synchronized on a single
computer, I read that you cannot reach nanosecond resolution for a NTP
synchronization even in a small LAN.
For large systems or distributed systems, a "global (synchronized) clock"
is not an option. You cannot synchronize clocks correctly, so your
algorithms must not rely on time, or at least not too precise resolution.
I am saying that to again repeat that we are far from sub-second nanosecond
resolution for system clock.
Le 24 oct. 2017 01:39, "Thomas Jollans" <tjol at tjol.eu> a écrit :
> On 22/10/17 17:06, Wes Turner wrote:
> > There are current applications with greater-than nanosecond precision:
> > - relativity experiments
> > - particle experiments
> > Must they always use their own implementations of time., datetime.
> > __init__, fromordinal, fromtimestamp ?!
> > - https://scholar.google.com/scholar?q=femtosecond
> > - https://scholar.google.com/scholar?q=attosecond
> > - GPS now supports nanosecond resolution
> > -
> Sure, but in these kinds of experiments you don't have a "timestamp" in
> the usual sense.
> You'll have some kind of high-precision "clock", but in most cases
> there's no way and no reason to synchronise this to wall time. You end
> up distinguishing between "macro-time" (wall time) and "micro-time"
> (time in the experiment relative to something)
> In a particle accelerator, you care about measuring relative times of
> almost-simultaneous detection events with extremely high precision.
> You'll also presumably have a timestamp for the event, but you won't be
> able or willing to measure that with anything like the same accuracy.
> While you might be able to say that you detected, say, a muon at
> 01:23:45.6789 at Δt=543.6ps*, you have femtosecond resolution, you have
> a timestamp, but you don't have a femtosecond timestamp.
> In ultrafast spectroscopy, we get a time resolution equal to the
> duration of your laser pulses (fs-ps), but all the micro-times measured
> will be relative to some reference laser pulse, which repeats at >MHz
> frequencies. We also integrate over millions of events - wall-time
> timestamps don't enter into it.
> In summary, yes, when writing software for experiments working with high
> time resolution you have to write your own implementations of whatever
> data formats best describe time as you're measuring it, which generally
> won't line up with time as a PC (or a railway company) looks at it.
> * The example is implausible not least because I understand muon
> chambers tend to be a fair bit bigger than 15cm, but you get my point.
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev