(Apologies, I've gotten a bit lost in the recent PEP-431 discussion on -dev. To recap, it concerns changing datetime to use UTC internally.) When doing datetime calculations, I read two major use cases, one I'll call "simple" (aka naive), and the other "robust", that comes into play when multiple users, zones, dst, leaps, and/or calendar requirements surface. Instead of ignoring one case, or trying to shoehorn several into one module, I submit the cases could be broken into at least two modules, to make it very easy for the end-developer to understand which approach to use and when. As a non-expert-in-the-area developer, I can say that it is difficult to look at the docs of datetime (and time) and know which approach to choose. Then when you do choose, it isn't clear which functions and constants to use with each other. Could we leave datetime supporting the simple/naive approach, deprecating robust features, and have another module built on top that expected/enforced robust UTC-based calculations? Could we also focus the documentation of each module to that end? -Mike
On Tue, Jul 28, 2015 at 10:10 PM, Mike Miller <python-ideas@mgmiller.net> wrote:
I agree with that, but I don't see a problem with having them in the same module. In my opinion you should get the simple case when you don't have time zone information added to your datetime objects, and the robust calculations when you do. The only problem from where I stand is that today's robust calculations are incorrect.
As a non-expert-in-the-area developer, I can say that it is difficult to look at the docs of datetime (and time) and know which approach to choose.
Documentation could probably be better... /Lennart
Hi, For whatever reason that make me strangely think of bytes vs unicode strings… Where you just s/simple case/str/s ; s/robust case/unicode/g and s/timezone/encoding/g Than being said, a new module might allow more flexibility in playing with the API, like in Delorean[1] for example. -- M [1] : http://delorean.readthedocs.org/en/latest/ On Tue, Jul 28, 2015 at 8:40 PM, Lennart Regebro <regebro@gmail.com> wrote:
On Wed, Jul 29, 2015 at 6:42 AM, Matthias Bussonnier <bussonniermatthias@gmail.com> wrote:
Two datetime modules with different API is definitely not a good idea. I do think a new module is necessary, but it should completely replace not just datetime, but also time. Maybe even calendar. There is overlap (and some cruft) between these modules, and it can be hard to understand exactly what function to use when, etc. //Lennart
Right, I was thinking largely the same API for both, with subclasses of the datetime objects with new behavior in the new module. I suppose, that the opposite could be done as well, write a new module with the new behavior, then replace datetime with a compatible api built from the new one if it made sense. -Mike On 07/28/2015 09:48 PM, Lennart Regebro wrote:
On Jul 29, 2015, at 06:48, Lennart Regebro <regebro@gmail.com> wrote:
That's not a bad idea. (Assuming you mean a very long-term deprecation or just "you probably shouldn't use this in new code, and it may be deprecated one of these decades" a la asyncore.) That would mean we get a sleep function, timing functions, etc. that take and return timedeltas instead of second or millis floats or ints, etc. You might want to go even farther and use datetime and timedelta objects in things like file times. It's a pretty big change, with a lot of backward compat risk, but the end result could be a much nicer stdlib.
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)
On Tue, Jul 28, 2015 at 10:10 PM, Mike Miller <python-ideas@mgmiller.net> wrote:
I agree with that, but I don't see a problem with having them in the same module. In my opinion you should get the simple case when you don't have time zone information added to your datetime objects, and the robust calculations when you do. The only problem from where I stand is that today's robust calculations are incorrect.
As a non-expert-in-the-area developer, I can say that it is difficult to look at the docs of datetime (and time) and know which approach to choose.
Documentation could probably be better... /Lennart
Hi, For whatever reason that make me strangely think of bytes vs unicode strings… Where you just s/simple case/str/s ; s/robust case/unicode/g and s/timezone/encoding/g Than being said, a new module might allow more flexibility in playing with the API, like in Delorean[1] for example. -- M [1] : http://delorean.readthedocs.org/en/latest/ On Tue, Jul 28, 2015 at 8:40 PM, Lennart Regebro <regebro@gmail.com> wrote:
On Wed, Jul 29, 2015 at 6:42 AM, Matthias Bussonnier <bussonniermatthias@gmail.com> wrote:
Two datetime modules with different API is definitely not a good idea. I do think a new module is necessary, but it should completely replace not just datetime, but also time. Maybe even calendar. There is overlap (and some cruft) between these modules, and it can be hard to understand exactly what function to use when, etc. //Lennart
Right, I was thinking largely the same API for both, with subclasses of the datetime objects with new behavior in the new module. I suppose, that the opposite could be done as well, write a new module with the new behavior, then replace datetime with a compatible api built from the new one if it made sense. -Mike On 07/28/2015 09:48 PM, Lennart Regebro wrote:
On Jul 29, 2015, at 06:48, Lennart Regebro <regebro@gmail.com> wrote:
That's not a bad idea. (Assuming you mean a very long-term deprecation or just "you probably shouldn't use this in new code, and it may be deprecated one of these decades" a la asyncore.) That would mean we get a sleep function, timing functions, etc. that take and return timedeltas instead of second or millis floats or ints, etc. You might want to go even farther and use datetime and timedelta objects in things like file times. It's a pretty big change, with a lot of backward compat risk, but the end result could be a much nicer stdlib.
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)
participants (7)
-
Andrew Barnert -
Guido van Rossum -
Lennart Regebro -
Matthias Bussonnier -
Mike Miller -
Neil Girdhar -
Rob Cliffe