[Python-Dev] [OT] Early PyCon Pictures, anyone?
Hi all, I've giving a talk on the history of PyCon at PyCon UK this weekend. I'd love to include some photos from the early conferences but alas most of the links I've found on the web are stale and broken. If anyone has pictures, or valid links to such pictures, I'd be delighted to hear about them. Thanks Steve Holden ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] iso8601 parsing
Hi, Could anyone put this five year-old bug about parsing iso8601 format date-times on the front burner? http://bugs.python.org/issue15873 In the comments there's a lot of hand-wringing about different variations that bogged it down, but right now I only need it to handle the output of datetime.isoformat(): >>> dt.isoformat() '2017-10-20T08:20:08.986166+00:00' Perhaps if we could get that minimum first step in, it could be iterated on and made more lenient in the future. Thank you, -Mike ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution
On Sun, Oct 22, 2017 at 1:42 PM, Wes Turner wrote: > 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)? > Well, numpy's datetime64 can be set to use (almost) whatever unit you want: https://docs.scipy.org/doc/numpy-1.13.0/reference/arrays. datetime.html#datetime-units Though it uses a single epoch, which I don't think ever made sense with femtoseconds And it has other problems, but it was designed that way, just for the reason. However, while there has been discussion of improvements, like making the epoch settable, none of them have happened, which makes me think that no one is using it for physics experiments, but rather plain old human calendar time... -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution
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. 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 [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] iso8601 parsing
If one simply replaces the 'T' with a space and trims it after the '.', IIRC, it parses fine. -- H On Oct 23, 2017 15:16, "Mike Miller" wrote: > Hi, > > Could anyone put this five year-old bug about parsing iso8601 format > date-times on the front burner? > > http://bugs.python.org/issue15873 > > In the comments there's a lot of hand-wringing about different variations > that bogged it down, but right now I only need it to handle the output of > datetime.isoformat(): > > >>> dt.isoformat() > '2017-10-20T08:20:08.986166+00:00' > > Perhaps if we could get that minimum first step in, it could be iterated > on and made more lenient in the future. > > Thank you, > -Mike > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/hasan. > diwan%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution
On Monday, October 23, 2017, Thomas Jollans 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 > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > wes.turner%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
