<div dir="ltr"><div><div><div><div><div><div><div><div><div>Honestly, I think some of these proposals are way too ambitious and will drown in a sea of bike-shedding.<br><br></div>Here's what I think is reasonable:<br><br></div>- 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.<br><br></div>- Keep the datetime module; it has its uses (and even fans), and again, deprecating would take decades.<br><br></div>- 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).<br><br></div>- 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.)<br><br><br></div>There are a few additional issues which I'm not sure are included in this discussion or not:<br><br></div>- 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.<br><br></div>- 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).<br><br></div>- 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.<br><div><div><div><div><div><div><div><div><div><div><div><br><div class="gmail_extra">-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div></div></div></div></div></div></div></div></div></div></div></div>