[Python-Dev] PEP 410, 3rd revision, Decimal timestamp

Victor Stinner victor.stinner at gmail.com
Mon Feb 20 14:01:54 CET 2012


>>> We must do better than Ruby: support arbritrary precision! :-D
>>
>> Seriously, I do consider that a necessary requirement for the PEP (which
>> the Decimal type actually meets). (...)
>
> (...)
> Not-quite-sure-how-seriously-you-intend-supporting-yoctoseconds-ly y'rs,

The point is not supporting yoctosecond resolution, but not having to
change the API each time that the resolution becomes better. The time
resolution already changed 3 times in UNIX/Linux history: 1 second, 1
ms, 1 us, 1 ns. So the C library has to maintain API for all these
resolution: time_t, timeb, timeval, timespec... ftime() and usleep()
are deperecated by POSIX 2008 for example.

http://news.bbc.co.uk/2/hi/technology/5099584.stm
"The prototype operates at speeds up to 500 gigahertz (GHz), more than
100 times faster than desktop PC chips."
"A decade ago we couldn't even envisage being able to run at these speeds."

500 Ghz means a theorical resolution of 2 picoseconds (10^-12). So
nanosecond might not be enough for next 10 years. This is theorical.

In practive, Linux does already use nanosecond timestamps and
shutil.copstat() has an issue with such timestamp (is unable to copy
such timestamp with no loss of precision).

Victor


More information about the Python-Dev mailing list