In any case, NTP is not the only thing that adjusts the clock, e.g. the
operating system will adjust the time for daylight savings.
Daylight savings time is not a clock adjustment, at least not in the sense
this thread has mostly been talking about the word clock. It doesn't
affect the
On 4/7/2012 5:49 AM, Victor Stinner wrote:
2012/4/7 Janzertjanz...@janzert.com:
On 4/5/2012 6:32 AM, Victor Stinner wrote:
I prefer to use CLOCK_MONOTONIC, not because it is also available for
older Linux kernels, but because it is more reliable. Even if the
underlying clock source is unstable
On Sat, Apr 7, 2012 at 4:56 PM, Glyph Lefkowitz gl...@twistedmatrix.comwrote:
On Apr 7, 2012, at 3:40 AM, Steven D'Aprano wrote:
In any case, NTP is not the only thing that adjusts the clock, e.g. the
operating system will adjust the time for daylight savings.
Daylight savings time is not
Is it still? I thought they fixed that ages ago?
On Mon, Apr 9, 2012 at 4:42 PM, Gregory P. Smith g...@krypto.org wrote:
On Sat, Apr 7, 2012 at 4:56 PM, Glyph Lefkowitz gl...@twistedmatrix.com
wrote:
On Apr 7, 2012, at 3:40 AM, Steven D'Aprano wrote:
In any case, NTP is not the only thing
On Mon, Apr 9, 2012 at 4:46 PM, Guido van Rossum gu...@python.org wrote:
Is it still? I thought they fixed that ages ago?
sadly, no. http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html
On Mon, Apr 9, 2012 at 4:42 PM, Gregory P. Smith g...@krypto.org wrote:
On Sat, Apr 7, 2012 at 4:56 PM,
2012/4/7 Janzert janz...@janzert.com:
On 4/5/2012 6:32 AM, Victor Stinner wrote:
I prefer to use CLOCK_MONOTONIC, not because it is also available for
older Linux kernels, but because it is more reliable. Even if the
underlying clock source is unstable (unstable frequency), a delta of
two
Victor Stinner wrote:
2012/4/7 Janzert janz...@janzert.com:
On 4/5/2012 6:32 AM, Victor Stinner wrote:
I prefer to use CLOCK_MONOTONIC, not because it is also available for
older Linux kernels, but because it is more reliable. Even if the
underlying clock source is unstable (unstable
2012/4/7 Steven D'Aprano st...@pearwood.info:
Victor Stinner wrote:
2012/4/7 Janzert janz...@janzert.com:
On 4/5/2012 6:32 AM, Victor Stinner wrote:
I prefer to use CLOCK_MONOTONIC, not because it is also available for
older Linux kernels, but because it is more reliable. Even if the
On 07Apr2012 20:40, Steven D'Aprano st...@pearwood.info wrote:
| Victor Stinner wrote:
| I don't think that NTP works like that. NTP only uses very smooth
adjustements:
[...]
| http://www.python.org/dev/peps/pep-0418/#ntp-adjustment
|
| That is incorrect. NTP by default will only slew the
On Apr 7, 2012, at 3:40 AM, Steven D'Aprano wrote:
In any case, NTP is not the only thing that adjusts the clock, e.g. the
operating system will adjust the time for daylight savings.
Daylight savings time is not a clock adjustment, at least not in the sense this
thread has mostly been
Cameron Simpson wrote:
I maintain that
monotonic still means what I said, and that it is the combination of
the word with clock that brings in your other criteria.
I'm not trying to redefine the word monotonic in general.
All I'm saying is that *if* the PEP is going to talk about
a monotonic
Steven D'Aprano wrote:
Greg Ewing wrote:
the important thing about a clock that it *keeps going forward*
That would be a *strictly* monotonic clock, as opposed to merely monotonic.
Well, yes, but even that's not enough -- it needs to go forward
at a reasonably constant rate, otherwise it's
On 6 April 2012 02:50, Cameron Simpson c...@zip.com.au wrote:
(Quoted from the Linux manpage)
All implementations support the system-wide real-time clock, which
is identified by CLOCK_REALTIME. Its time represents seconds and
nanoseconds since the Epoch. When its time is changed,
On Thu, Apr 5, 2012 at 12:32, Victor Stinner victor.stin...@gmail.com wrote:
I prefer to use CLOCK_MONOTONIC, not because it is also available for
older Linux kernels, but because it is more reliable. Even if the
underlying clock source is unstable (unstable frequency), a delta of
two reads of
On 4 April 2012 10:33, Steven D'Aprano st...@pearwood.info wrote:
try:
from os import bestclock as _bestclock
except ImportError:
_bestclock = time
My problem here is that best clock means different things to different
people (as the number of emails shows).
I think exposing specific
1. The steadiest clock on the system. Ideally this would be a steady
clock, but may not be.
time.monotonic() as proposed in the PEP 418 *is* the steadiest
available clock, but we cannot say that it is steady :-)
2. The most precise clock on the system. This would have the finest-grain
tick
On 4/5/2012 6:32 AM, Victor Stinner wrote:
Since the only monotonic clock that can be adjusted by NTP is Linux'
CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
give a clock that isn't adjusted by NTP.
I thought we decided that NTP adjustment isn't an issue, because
it's
On Thu, Apr 5, 2012 at 00:45, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Lennart Regebro wrote:
Since the only monotonic clock that can be adjusted by NTP is Linux'
CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
give a clock that isn't adjusted by NTP.
I thought we
Since the only monotonic clock that can be adjusted by NTP is Linux'
CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
give a clock that isn't adjusted by NTP.
I thought we decided that NTP adjustment isn't an issue, because
it's always gradual.
Well, in timings it is an
2012/4/5 PJ Eby p...@telecommunity.com:
More details why it's hard to define such function and why I dropped
it from the PEP.
If someone wants to propose again such function (monotonic or
fallback to system clock), two issues should be solved:
- name of the function
- description of the
Cameron Simpson wrote:
On 04Apr2012 22:23, PJ Eby p...@telecommunity.com wrote:
| On Apr 4, 2012 7:28 PM, Victor Stinner victor.stin...@gmail.com wrote:
| More details why it's hard to define such function and why I dropped
| it from the PEP.
|
| If someone wants to propose again such
On Thu, 05 Apr 2012 08:32:22 -0700
Ethan Furman et...@stoneleaf.us wrote:
Steven D'Aprano's synthetic clock is able to partially avoid that
situation -- worst case is a timeout of double what you asked for -- so
10 seconds instead of 5 (which is much better than 3600!).
The remaining issue
On Wed, Apr 4, 2012 at 11:41 PM, Cameron Simpson c...@zip.com.au wrote:
On 04Apr2012 22:23, PJ Eby p...@telecommunity.com wrote:
| On Apr 4, 2012 7:28 PM, Victor Stinner victor.stin...@gmail.com
wrote:
| More details why it's hard to define such function and why I dropped
| it from the
On Thu, Apr 5, 2012 at 6:34 AM, Victor Stinner victor.stin...@gmail.comwrote:
2012/4/5 PJ Eby p...@telecommunity.com:
More details why it's hard to define such function and why I dropped
it from the PEP.
If someone wants to propose again such function (monotonic or
fallback to system
On Thu, Apr 5, 2012 at 9:48 AM, PJ Eby p...@telecommunity.com wrote:
On Thu, Apr 5, 2012 at 6:34 AM, Victor Stinner victor.stin...@gmail.com
wrote:
2012/4/5 PJ Eby p...@telecommunity.com:
More details why it's hard to define such function and why I dropped
it from the PEP.
If someone
On Thu, 5 Apr 2012 09:56:19 -0700
Guido van Rossum gu...@python.org wrote:
For timeout purposes in a single process, such a clock is useful. It just
isn't suitable for benchmarks, or for interprocess coordination.
I think it would be better if the proposed algorithm (or whatever
For timeout purposes in a single process, such a clock is useful. It just
isn't suitable for benchmarks, or for interprocess coordination.
I think it would be better if the proposed algorithm (or whatever
algorithm to fix timeouts) was implemented by the
application/library code using the
Victor Stinner wrote:
I changed time.monotonic() to not fallback to the system clock exactly
for this reason: Python cannot guess what the developer expects, or
how the developer will use the clock.
Which is exactly why I like Cameron Simpson's approach to selecting a
clock -- let the
On Thu, Apr 5, 2012 at 12:56 PM, Guido van Rossum gu...@python.org wrote:
Depending on the polling frequency sounds like a bad idea, since you
can't know that you're the only user of the clock. Also depending on
the use case, too short a timeout may be worse than too long a
timeout.
Given a
Folks:
Good job, Victor Stinner on baking the accumulated knowledge of this
thread into PEP 418. Even though I'm very interested in the topic, I
haven't been able to digest the whole thread(s) on the list and
understand what the current collective understanding is. The detailed
PEP document helps
On 05Apr2012 09:56, Guido van Rossum gu...@python.org wrote:
| On Thu, Apr 5, 2012 at 9:48 AM, PJ Eby p...@telecommunity.com wrote:
| What's missing is that if you're using a monotonic clock for timeouts, then
| a monotonically-adjusted system clock can do that, subject to the polling
|
On 05Apr2012 13:39, Zooko Wilcox-O'Hearn zo...@zooko.com wrote:
| Good job, Victor Stinner on baking the accumulated knowledge of this
| thread into PEP 418. Even though I'm very interested in the topic, I
| haven't been able to digest the whole thread(s) on the list and
| understand what the
On Apr 5, 2012 11:01 AM, Guido van Rossum gu...@python.org wrote:
I think it would be better if the proposed algorithm (or whatever
algorithm to fix timeouts) was implemented by the
application/library code using the timeout (or provided as a separate
library function), rather than by the
Cameron Simpson wrote:
A monotonic clock never returns t0 t1 for t0, t1 being two adjacent
polls of the clock. On its own it says nothing about steadiness or
correlation with real world time.
No, no, no.
This is the strict mathematical meaning of the word monotonic,
but the way it's used in
On 06Apr2012 13:14, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
| Cameron Simpson wrote:
| A monotonic clock never returns t0 t1 for t0, t1 being two adjacent
| polls of the clock. On its own it says nothing about steadiness or
| correlation with real world time.
|
| No, no, no.
| This is
Greg Ewing wrote:
Cameron Simpson wrote:
A monotonic clock never returns t0 t1 for t0, t1 being two adjacent
polls of the clock. On its own it says nothing about steadiness or
correlation with real world time.
No, no, no.
This is the strict mathematical meaning of the word monotonic,
but
On Wed, Apr 04, 2012 at 03:28:34AM +0200, Victor Stinner wrote:
Le 04/04/2012 02:33, Steven D'Aprano a écrit :
Judging by the hundreds of emails regarding PEP 418, the disagreements
about APIs, namings, and even what characteristics clocks should have, I
believe that the suggestion is too
On Wed, 4 Apr 2012 18:09:40 +1000
Steven D'Aprano st...@pearwood.info wrote:
Python 3.3 has already time.clock_gettime() and time.clock_getres() with
CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW, CLOCK_HIGHRES.
Why does it already have these things when the PEP is not accepted?
Why does it already have these things when the PEP is not accepted?
...
(This is not a rhetorical question, perhaps there is a good reason why
these have been added independently of the PEP.)
time.clock_gettime() friends were added by the issue #10278. The
function was added before someone
I failed to propose a consistent and clear API because I (and Guido!) wanted
to fallback to the system clock. Falling back to the system clock is a
problem when you have to define the function in the documentation or if you
don't want to use the system clock (but do something else) if no
I am fine with the PEP as it is now (2012-04-04 15:34 GMT).
A question:
Since the only monotonic clock that can be adjusted by NTP is Linux'
CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
give a clock that isn't adjusted by NTP. That would however mean we
wouldn't support
On 2012-04-03, at 9:28 PM, Victor Stinner wrote:
In the last version of my PEP, time.monotonic() is simply defined as a
monotonic clock (cannot go backward). There is no more ... best ... in its
definition.
I like the last version of the PEP ;)
-
Yury
I failed to propose a consistent and clear API because I (and Guido!) wanted
to fallback to the system clock. Falling back to the system clock is a
problem when you have to define the function in the documentation or if you
don't want to use the system clock (but do something else) if no
Lennart Regebro wrote:
Since the only monotonic clock that can be adjusted by NTP is Linux'
CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
give a clock that isn't adjusted by NTP.
I thought we decided that NTP adjustment isn't an issue, because
it's always gradual.
--
On Apr 4, 2012 7:28 PM, Victor Stinner victor.stin...@gmail.com wrote:
More details why it's hard to define such function and why I dropped
it from the PEP.
If someone wants to propose again such function (monotonic or
fallback to system clock), two issues should be solved:
- name of the
On 04Apr2012 22:23, PJ Eby p...@telecommunity.com wrote:
| On Apr 4, 2012 7:28 PM, Victor Stinner victor.stin...@gmail.com wrote:
| More details why it's hard to define such function and why I dropped
| it from the PEP.
|
| If someone wants to propose again such function (monotonic or
|
On Thu, Apr 5, 2012 at 1:41 PM, Cameron Simpson c...@zip.com.au wrote:
It was pointed out (by Nick Coglan I think?) that if the system clock
stepped backwards then a timeout would be extended by at least that
long.
Guido pointed it out (it was in a reply to me, though).
Cheers,
Nick.
--
Judging by the hundreds of emails regarding PEP 418, the disagreements about
APIs, namings, and even what characteristics clocks should have, I believe
that the suggestion is too divisive (and confusing!) to be accepted or
rejected at this time.
Everyone has a different opinion, everyone
On Wed, Apr 4, 2012 at 10:33 AM, Steven D'Aprano st...@pearwood.info wrote:
Python has worked pretty well without high res and monotonic clocks for 20
years. Let's not rush into a suboptimal design based on who can outlast
everyone else in this discussion.
+1
FWIW, I'd be fine with underscore
Le 04/04/2012 02:33, Steven D'Aprano a écrit :
Judging by the hundreds of emails regarding PEP 418, the disagreements
about APIs, namings, and even what characteristics clocks should have, I
believe that the suggestion is too divisive (and confusing!) to be
accepted or rejected at this time.
On 2012-04-03, at 8:33 PM, Steven D'Aprano wrote:
1) the os module should expose lightweight wrappers around whatever clocks
the operating system provides;
+1. That should make it flexible enough to those who really need it.
2) the time module should NOT provide any further clocks other
Finally! We've come full circle.
+1 for monotonic as just described by Victor.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Lock it in before the paint dries.
On Apr 4, 2012 10:05 AM, Matt Joiner anacro...@gmail.com wrote:
Finally! We've come full circle.
+1 for monotonic as just described by Victor.
___
Python-Dev mailing list
Python-Dev@python.org
53 matches
Mail list logo
