[Python-ideas] Reduce platform dependence of date and time related functions

random832 at fastmail.us random832 at fastmail.us
Tue Sep 17 18:01:43 CEST 2013


On Mon, Sep 16, 2013, at 15:02, Alexander Belopolsky wrote:
> On Mon, Sep 16, 2013 at 2:49 PM, <random832 at fastmail.us> wrote:
> > I propose supplying pure-python implementations (in accordance with PEP
> > 399) for the entire datetime module
> 
> We already have that in python 3.x:
> 
> http://bugs.python.org/issue7989

Sorry - it was unclear to me that simply clicking "browse" from
http://hg.python.org/cpython/ did not result in browsing the latest
source. (What branch is that? It's not "default")

> The idea to provide pure python implementation of the time module was
> proposed and rejected:
> 
> http://bugs.python.org/issue9528

This is a much more limited scope than that. I was merely proposing a
limited set of functions - this could be implemented in the same way as
the posix module, with a small pure python module that imports
everything from the larger C module. These could simply be implemented
in C instead - are we guaranteed to have a 64-bit integer type
available? My main concern (for pure python vs C) was whether or not it
is possible to work with greater than 32 bit values on a 32 bit system.
If necessary we could do some of the work in double - the input is
double, anyway, so it won't be outside that range.

Do you have any thoughts on the rest of the proposal (that gmtime,
timegm, and strftime should have unlimited - or at least not limited to
low platform-specific limits like 1970 or 2038 - range, that python
"epoch timestamps" should be defined as beginning in 1970 and not
including leap seconds regardless of hypothetical [I don't believe any
currently supported systems actually do, except to the extent that
individual Unix sites can use so-called "right" tz data] systems that
may have a time_t that behaves otherwise, that tm_gmtoff and tm_zone
should always be provided)?

One concern for strftime in particular is locale support. It may be
difficult to query the relevant locale data in a portable manner.


More information about the Python-ideas mailing list