[Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Wes Turner wes.turner at gmail.com
Mon Oct 23 22:18:42 EDT 2017


On Monday, October 23, 2017, Thomas Jollans <tjol at tjol.eu> wrote:

> 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.


(Sorry, maybe too OT)

So these experiments are all done in isolation; referent to t=0.

> Aligning simulation data in context to other events may be enlightening:


IIUC,
https://en.wikipedia.org/wiki/Quantum_mechanics_of_time_travel implies that
there are (or may) Are potentially connections between events over greater
periods of time.

It's unfortunate that aligning this data requires adding offsets and
working with nonstandard adhoc time structs.

A problem for another day, I suppose.

Thanks for adding time_ns(l.


> Cheers
> Thomas
>
>
> * 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 <javascript:;>
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> wes.turner%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171023/a19b7bbb/attachment.html>


More information about the Python-Dev mailing list