[Python-ideas] Reduce platform dependence of date and time related functions
random832 at fastmail.us
random832 at fastmail.us
Mon Sep 16 20:49:11 CEST 2013
The practice of using OS functions for time handling has its worst
effects on Windows, where many functions are unable to process times
from before 1970-01-01 even though there is no reason for Python to have
such a limitation. It also results in uneven support for strftime
specifiers. Some of these functions also suffer from the Year 2038
problem on OSes with a 32-bit time_t type.
I propose supplying pure-python implementations (in accordance with PEP
399) for the entire datetime module, and additionally the asctime,
strftime, strptime, and gmtime functions in the time module, and
calendar.timegm. Unfortunately, functions dealing with local time stamps
in the system's idea of local time are still dependent on the platform's
C library functions (localtime, mktime, ctime)
Or, if this is not practical, supplying alternate implementations of the
relevant C functions, and calling these instead wherever these are used.
If it is practical to do so, these functions should use python integers
as the type for timestamps; if not, they should use 64-bit integers in
preference to the platform time_t.
Is it reasonable to expose the possibility of an epoch other than 1970
(or of timestamps that handle leap seconds in a different manner than
POSIX) at a python level? Even if such a platform ever comes to be
supported, it could be done so with a layer that hides these
differences.
More information about the Python-ideas
mailing list