Greetings, Is there interest in a PEP for extending time, datetime / timedelta for arbitrary or extended precision fractional seconds? My company designs and manufactures scientific hardware that typically operate with nanoseconds -- sometimes even attoseconds -- levels of precision. We’re in the process of providing Python APIs for some of these products and need to expose the full accuracy of the data to our customers. Doing so would allow developers to do things like timestamp analog measurements for correlating with other events in their system, or precisely schedule a future time event for correctly interoperating with other high-speed devices. The API we’ve been toying with is adding two new fields to time, datetime and timedelta - frac_seconds (int) - frac_seconds_exponent (int or new SITimeUnit enum) time.microseconds would be turned into a property that wraps frac_seconds for compatibility Challenges - Defining the new `max` or `resolution` - strftime / strptime. I propose that we do nothing, just leave formatting / parsing to use `microseconds` at best. On the other hand, __str__ could just specify the fractional seconds using scientific or engineering notation. Alternatives - My company create our own datetime library - Continued fracturing of time ... ecosystem (datetime, arrow, pendulum, delorean, datetime64, pandas.Timestamp – all of which offer varying degrees of compatibility) - Add an `attosecond` field and have `microsecond` wrap this. - Effectively same except hard code `frac_seconds_exponent` to lowest value - The most common cases (milliseconds, microseconds) will always pay the cost of using a bigint as compared to the proposal which is a "pay for what you use" approach - How do we define what is "good enough" precision? - Continue to subdivide time by adding `nanosecond` that is "nanoseconds since last micosecond", `picosecond` that is "picoseconds since last micnanosecond", and `attosecond` field that is "attoseconds since last picosecond" - Possibly surprising API; people might expect `picosecond` to be an offset since last second - Messy base 10 / base 2 conversions - Have `frac_seconds` be a float - This has precision issues. If anyone wants to have an impromptu BoF on the subject, I'm available at PyCon.
Thanks Ed Page _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
