On Thu, May 10, 2018 at 6:13 PM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
> Is there interest in a PEP for extending time, datetime / timedelta for
arbitrary or extended precision fractional seconds?

Having seen the utter disaster that similar ideas brought to numpy, I would
say: no.

I'm not sure the "disaster" was due to this idea.... nor, frankly, is datetime64 a disaster at all, though certainly far from perfect.

But my question is whether high precision timedeltas belongs with "calendar time" at all.

What with UTC and leap seconds, and all that, it gets pretty ugly, when down to the second or sub-second, what a given datetime really means.

If I were to work with high precision measurements, experiments, etc, I'd use a "nanoseconds since" representation, where the "epoch" would likely be the beginning of the experiment, of something relevant.

Note that this issued in netcdf CF formats, datetimes are expressed in things like:

"hours since 1970-01-01:00:00"

granted, it's mostly so that the values can be stored as an array of a simple scalars, but it does allow precision and an epoch that are suited to the data at hand.

NOTE: One source of the "disaster" of numpy's datetime64 is you can set teh precision, but NOT the epoch -- which is kind of problematic if you really want femtosecond precision for something not in 1970 :-)


On the other hand, nanoseconds are slowly making their way to the stdlib
and to add nanoseconds to datetime we only need a fully backward compatible
implementation, not even a PEP.

See <https://bugs.python.org/issue15443>.
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/


Christopher Barker, Ph.D.

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