On AIX, time.thread_time() is now implemented with thread_cputime()
which has nanosecond resolution, rather than
clock_gettime(CLOCK_THREAD_CPUTIME_ID) which has a resolution of 10 ms.
Calling setlocale(LC_CTYPE, "") on a system where GetACP() returns CP_UTF8 results in empty strings in _tzname[].
This causes time.tzname to be an empty string.
I have reported the bug to the UCRT team and will follow up, but it will take some time get a fix into production.
In the meantime one possible workaround is to temporarily change the locale by calling setlocale(LC_CTYPE, "C") before calling _tzset and restore the current locale after if the GetACP() == CP_UTF8 or CP_UTF7
@zooba
https://bugs.python.org/issue36779
Fix time.mktime() error handling on AIX for year before 1970.
Other changes:
* mktime(): rename variable 'buf' to 'tm'.
* _PyTime_localtime():
* Use "localtime" rather than "ctime" in the error message
(specific to AIX).
* Always initialize errno to 0 just in case if localtime_r()
doesn't set errno on error.
* On AIX, avoid abs() which is limited to int type.
* EINVAL constant is now always available.
Add Clang Memory Sanitizer build instrumentation to work around
false positives from the socket and time modules as well as skipping
a couple test_faulthandler tests.
* Fix test_mktime on AIX by adding code to get mktime to behave the
same way as it does on other *nix systems
* Fix test_pthread_getcpuclickid in AIX by adjusting the test case
expectations when running on AIX in 32-bit mode
Patch by Michael Felt.
* PyInit_time() now returns NULL if an exception is raised.
* Rename PyInit_timezone() to init_timezone(). "PyInit_" prefix is
a special prefix for function initializing a module.
init_timezone() doesn't initialize a module and the function is not
exported.
get_gmtoff() now returns time_t instead of int to fix the following
Visual Studio warning:
Modules\timemodule.c(1183): warning C4244: 'return':
conversion from 'time_t' to 'int', possible loss of data
Reduce the knotty preprocessor conditional logic, dedent unnecessarily nested
code, and handle errors properly.
The first edition of this change (afde1c1a05)
failed (bpo-34715) because FreeBSD doesn't define the timezone globals. That's
why we're now checking for HAVE_DECL_TZNAME.
Modify locale.localeconv(), time.tzname, os.strerror() and other
functions to ignore the UTF-8 Mode: always use the current locale
encoding.
Changes:
* Add _Py_DecodeLocaleEx() and _Py_EncodeLocaleEx(). On decoding or
encoding error, they return the position of the error and an error
message which are used to raise Unicode errors in
PyUnicode_DecodeLocale() and PyUnicode_EncodeLocale().
* Replace _Py_DecodeCurrentLocale() with _Py_DecodeLocaleEx().
* PyUnicode_DecodeLocale() now uses _Py_DecodeLocaleEx() for all
cases, especially for the strict error handler.
* Add _Py_DecodeUTF8Ex(): return more information on decoding error
and supports the strict error handler.
* Rename _Py_EncodeUTF8_surrogateescape() to _Py_EncodeUTF8Ex().
* Replace _Py_EncodeCurrentLocale() with _Py_EncodeLocaleEx().
* Ignore the UTF-8 mode to encode/decode localeconv(), strerror()
and time zone name.
* Remove PyUnicode_DecodeLocale(), PyUnicode_DecodeLocaleAndSize()
and PyUnicode_EncodeLocale() now ignore the UTF-8 mode: always use
the "current" locale.
* Remove _PyUnicode_DecodeCurrentLocale(),
_PyUnicode_DecodeCurrentLocaleAndSize() and
_PyUnicode_EncodeCurrentLocale().
Add new time functions:
* time.clock_gettime_ns()
* time.clock_settime_ns()
* time.monotonic_ns()
* time.perf_counter_ns()
* time.process_time_ns()
* time.time_ns()
Add new _PyTime functions:
* _PyTime_FromTimespec()
* _PyTime_FromNanosecondsObject()
* _PyTime_FromTimeval()
Other changes:
* Add also os.times() tests to test_os.
* pytime_fromtimeval() and pytime_fromtimeval() now return
_PyTime_MAX or _PyTime_MIN on overflow, rather than undefined
behaviour
* _PyTime_FromNanoseconds() parameter type changes from long long to
_PyTime_t
Fix timeout rounding in time.sleep(), threading.Lock.acquire() and
socket.socket.settimeout() to round correctly negative timeouts between -1.0 and
0.0. The functions now block waiting for events as expected. Previously, the
call was incorrectly non-blocking.
bpo-31803: time.clock() and time.get_clock_info('clock') now emit a
DeprecationWarning warning.
Replace time.clock() with time.perf_counter() in tests and demos.
Remove also hasattr(time, 'monotonic') in test_time since time.monotonic()
is now always available since Python 3.5.
* Rewrite win_perf_counter() to only use integers internally.
* Add _PyTime_MulDiv() which compute "ticks * mul / div"
in two parts (int part and remaining) to prevent integer overflow.
* Clock frequency is checked at initialization for integer overflow.
* Enhance also pymonotonic() to reduce the precision loss on macOS
(mach_absolute_time() clock).
time.clock() and time.perf_counter() now use again C double
internally.
Remove also _PyTime_GetWinPerfCounterWithInfo(): use
_PyTime_GetPerfCounterDoubleWithInfo() instead on Windows.
* Separated functions and constants descriptions in sections.
* Added a note about the limitations of timezone constants.
* Removed redundant lists from the module docstring.
bpo-28769 changed PyUnicode_AsUTF8() return type from const char* to
char* in Python 3.7, but tm_zone field type of the tm structure is
char* on FreeBSD.
Cast PyUnicode_AsUTF8() to char* in gettmarg() to fix the warning:
Modules/timemodule.c:443:20: warning: assigning to 'char *'
from 'const char *' discards qualifiers
timegm() return type is time_t, not int. Use time_t to prevent the
following compiler warning on Windows:
timemodule.c: warning C4244: '=': conversion from 'time_t' to 'int',
possible loss of data
Only define the get_zone() and get_gmtoff() private functions in the
time module if these functions are needed to initialize the module.
The change fixes the following warnings on AIX:
Modules/timemodule.c:1175:1: warning: 'get_gmtoff' defined but not used [-Wunused-function]
Modules/timemodule.c:1164:1: warning: 'get_zone' defined but not used [-Wunused-function]
Issue #28915: Use PyObject_Call() to pass a tuple of positional arguments,
instead of relying on _PyObject_CallMethodId() weird behaviour to unpack the
tuple.
* _PyTime_AsTimeval() now ensures that tv_usec is always positive
* _PyTime_AsTimespec() now ensures that tv_nsec is always positive
* _PyTime_AsTimeval() now returns an integer on overflow instead of raising an
exception
* Rename _PyTime_FromObject() to _PyTime_FromSecondsObject()
* Add _PyTime_AsNanosecondsObject() and _testcapi.pytime_fromsecondsobject()
* Add unit tests
In practice, _PyTime_t is a number of nanoseconds. Its C type is a 64-bit
signed number. It's integer value is in the range [-2^63; 2^63-1]. In seconds,
the range is around [-292 years; +292 years]. In term of Epoch timestamp
(1970-01-01), it can store a date between 1677-09-21 and 2262-04-11.
The API has a resolution of 1 nanosecond and use integer number. With a
resolution on 1 nanosecond, 64-bit IEEE 754 floating point numbers loose
precision after 194 days. It's not the case with this API. The drawback is
overflow for values outside [-2^63; 2^63-1], but these values are unlikely for
most Python modules, except of the datetime module.
New functions:
- _PyTime_GetMonotonicClock()
- _PyTime_FromObject()
- _PyTime_AsMilliseconds()
- _PyTime_AsTimeval()
This change uses these new functions in time.sleep() to avoid rounding issues.
The new API will be extended step by step, and the old API will be removed step
by step. Currently, some code is duplicated just to be able to move
incrementally, instead of pushing a large change at once.
interrupted by a signal
Add a new _PyTime_AddDouble() function and remove _PyTime_ADD_SECONDS() macro.
The _PyTime_ADD_SECONDS only supported an integer number of seconds, the
_PyTime_AddDouble() has subsecond resolution.
retried with the recomputed delay, except if the signal handler raises an
exception (PEP 475).
Modify also test_signal to use a monotonic clock instead of the system clock.
threading.Lock.acquire(), threading.RLock.acquire() and socket operations now
use a monotonic clock, instead of the system clock, when a timeout is used.
QueryPerformanceFrequency() cannot fail on Windows XP and later according to
its documentation: raise an exception on error and drop the fallback to the
system clock.
Other changes:
* The whole _PyTime API is private (not defined if Py_LIMITED_API is set)
* _PyTime_gettimeofday_info() also returns -1 on error
* Simplify PyTime_gettimeofday(): only use clock_gettime(CLOCK_REALTIME) or
gettimeofday() on UNIX. Don't fallback to ftime() or time() anymore.
clock_gettime(CLOCK_REALTIME) if available. As a side effect, Python now
depends on the librt library on Solaris and on Linux (only with glibc older
than 2.17).
PyStructSequence_InitType() except that it has a return value (0 on success,
-1 on error).
* PyStructSequence_InitType2() now raises MemoryError on memory allocation failure
* Fix also some calls to PyDict_SetItemString(): handle error
On AIX, the C function mktime() alwaysd sets tm_wday, even on error. So tm_wday
cannot be used as a sentinel to detect an error, we can only check if the
result is (time_t)-1.