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

[Brett Cannon]

On Tue, Sep 17, 2013 at 12:01 PM, <random832 at fastmail.us> wrote:

> 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")
>

Depends on the last commit (it's an hgweb thing; always specify the branch).


>
> > 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.


You also have the issue that if you port strftime then you lose the pure
Python port of strptime:
http://hg.python.org/cpython/file/default/Lib/_strptime.py
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130917/aa147964/attachment-0001.html>