[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
Am 15.02.2012 21:06, schrieb Antoine Pitrou:
> On Wed, 15 Feb 2012 20:56:26 +0100
> "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> With the quartz in Victor's machine, a single clock takes 0.3ns, so
>> three of them make a nanosecond. As the quartz may not be entirely
>> accurate (and also as the CPU frequency may change) you have to measure
>> the clock rate against an external time source, but Linux has
>> implemented algorithms for that. On my system, dmesg shows
>> [ 2.236894] Refined TSC clocksource calibration: 2793.000 MHz.
>> [ 2.236900] Switching to clocksource tsc
> But that's still not meaningful. By the time clock_gettime() returns,
> an unpredictable number of nanoseconds have elapsed, and even more when
> returning to the Python evaluation loop.
This is not exactly true: while the current time won't be what was
returned when using it, it is certainly possible to predict how long it
takes to return from a system call. So the result is not accurate, but
If you are formally arguing that uncertain evens may happen, such as
the scheduler interrupting the thread: this is true for any clock
reading; the actual time may be many milliseconds off by the time it
is used. That is no reason to return to second resolution.
> So the nanosecond precision is just an illusion, and a float should
> really be enough to represent durations for any task where Python is
> suitable as a language.
I agree with that statement - I was just refuting your claim that Linux
cannot do nanosecond measurements.
Please do recognize the point I made to Guido: despite us three agreeing
that a float is good enough for time stamps, people will continue to
submit patches and ask for new features until we give in.
One way to delay that by several years could be to reject the PEP in
a way that makes it clear that not only the specific approach is
rejected, but any approach using anything else but floats.