[Datetime-SIG] The BDFL's take

Guido van Rossum guido at python.org
Wed Jul 29 12:40:51 CEST 2015


[I posted this to python-ideas, but then found that this SIG was created.
So let's discuss it here.]


Honestly, I think some of these proposals are way too ambitious and will
drown in a sea of bike-shedding.

Here's what I think is reasonable:

- Keep the time module; POSIX timestamps represented as floats are still
very useful (and ubiquitous in other APIs), and it would take decades to
deprecate.

- Keep the datetime module; it has its uses (and even fans), and again,
deprecating would take decades.

- Add a few convenience APIs to one or both of the above for better
conversion between various forms of datetime and POSIX timestamps (I think
there are a few missing APIs in this area).

- Design a new module with a separate API for "human time manipulation".
This is where operations belong like "add 1 month" or "add 1 day" with
heuristics for edge cases (e.g. months of different lengths due to calendar
conventions, and the occasional short or long day due to DST). Possibly
this can borrow some API and/or implementation from pytz. Possibly it could
be made available as a 3rd party module on PyPI first, to get it
user-tested in quick iterations (quicker than core Python releases,
anyway). But that doesn't preclude also writing a PEP. This module needs to
interface somehow with the datetime module (and possibly also with the time
module) in ways that need some serious thinking -- that's where I expect
the hard part of writing the PEP will be. (Maybe a "human timedelta" type
would be useful here? Eventually this might even be added to the datetime
module.)


There are a few additional issues which I'm not sure are included in this
discussion or not:

- A unified API for accessing an up-to-date timezone database. This has
been discussed in the past, and we couldn't find a solution that satisfied
all requirements (the main problem being different platform expectations
IIRC), but it's probably worth it trying again.

- Nanosecond precision? I'm not against adding this to the datetime module,
as long as backward compatibility is somehow preserved, especially for
pickles (maybe nanoseconds default to zero unless explicitly requested or
specified).

- An "is_dst" flag for datetime objects. Again, this should default to
"backwards compatible" (== "don't care", the -1 value in struct tm) so that
pickles are two-way compatible with Python 3.5 and before.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150729/b800ee82/attachment.html>


More information about the Datetime-SIG mailing list