[Python-Dev] PEP 410, 3rd revision, Decimal timestamp (original) (raw)
Victor Stinner victor.stinner at gmail.com
Mon Feb 20 14:01:54 CET 2012
- Previous message: [Python-Dev] PEP 410, 3rd revision, Decimal timestamp
- Next message: [Python-Dev] Status of PEP 397 - Python launcher for Windows
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] PEP 410, 3rd revision, Decimal timestamp
- Next message: [Python-Dev] Status of PEP 397 - Python launcher for Windows
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]