Skip to content

Commit c3c616c

Browse files
committed
Issue #24707: Remove assertion in monotonic clock
Don't check anymore at runtime that the monotonic clock doesn't go backward. Yes, it happens. It occurs sometimes each month on a Debian buildbot slave running in a VM. The problem is that Python cannot do anything useful if a monotonic clock goes backward. It was decided in the PEP 418 to not fix the system, but only expose the clock provided by the OS.
1 parent 4912e7a commit c3c616c

File tree

1 file changed

+0
-10
lines changed

1 file changed

+0
-10
lines changed

Python/pytime.c

-10
Original file line numberDiff line numberDiff line change
@@ -533,10 +533,6 @@ _PyTime_GetSystemClockWithInfo(_PyTime_t *t, _Py_clock_info_t *info)
533533
static int
534534
pymonotonic_new(_PyTime_t *tp, _Py_clock_info_t *info, int raise)
535535
{
536-
#ifdef Py_DEBUG
537-
static int last_set = 0;
538-
static _PyTime_t last = 0;
539-
#endif
540536
#if defined(MS_WINDOWS)
541537
ULONGLONG result;
542538

@@ -627,12 +623,6 @@ pymonotonic_new(_PyTime_t *tp, _Py_clock_info_t *info, int raise)
627623
}
628624
if (_PyTime_FromTimespec(tp, &ts, raise) < 0)
629625
return -1;
630-
#endif
631-
#ifdef Py_DEBUG
632-
/* monotonic clock cannot go backward */
633-
assert(!last_set || last <= *tp);
634-
last = *tp;
635-
last_set = 1;
636626
#endif
637627
return 0;
638628
}

0 commit comments

Comments
 (0)