FAQ
(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

Search Discussions

  • Lennart Regebro at Jul 29, 2015 at 3:40 am

    On Tue, Jul 28, 2015 at 10:10 PM, Mike Miller wrote:
    (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.

    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
  • Matthias Bussonnier at Jul 29, 2015 at 4:42 am
    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 wrote:
    On Tue, Jul 28, 2015 at 10:10 PM, Mike Miller wrote:
    (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.
    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
    _______________________________________________
    Python-ideas mailing list
    Python-ideas at python.org
    https://mail.python.org/mailman/listinfo/python-ideas
    Code of Conduct: http://python.org/psf/codeofconduct/
  • Lennart Regebro at Jul 29, 2015 at 4:48 am

    On Wed, Jul 29, 2015 at 6:42 AM, Matthias Bussonnier wrote:
    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.

    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
  • Mike Miller at Jul 29, 2015 at 8:38 am
    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:
      >
    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
  • Andrew Barnert at Jul 29, 2015 at 9:52 am

    On Jul 29, 2015, at 06:48, Lennart Regebro wrote:
    On Wed, Jul 29, 2015 at 6:42 AM, Matthias Bussonnier
    wrote:
    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.
    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.

    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.
  • Lennart Regebro at Jul 29, 2015 at 10:07 am

    On Wed, Jul 29, 2015 at 11:52 AM, Andrew Barnert wrote:
    On Jul 29, 2015, at 06:48, Lennart Regebro wrote:
    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.
    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.)

    Exactly. The time and datetime modules would then hang around until
    some sort of big "we are gonna remove the stdlib cruft" in a future
    Python X.0.


    But I only have vague ideas so far.


    //Lennart
  • Guido van Rossum at Jul 29, 2015 at 10:20 am
    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/python-ideas/attachments/20150729/51297ef9/attachment.html>
  • Guido van Rossum at Jul 29, 2015 at 10:42 am
    Oops, let's move this to datetime-sig. I've reposted this there under the
    subject "The BDFL's take".


    On Wed, Jul 29, 2015 at 12:20 PM, Guido van Rossum wrote:

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

    --
    --Guido van Rossum (python.org/~guido)
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150729/0b1e3ff6/attachment-0001.html>
  • Rob Cliffe at Jul 29, 2015 at 11:10 am

    On 29/07/2015 05:48, Lennart Regebro 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.
    +1.
  • Neil Girdhar at Jul 29, 2015 at 6:08 pm
    +1 for one unified module.

    On Wednesday, July 29, 2015 at 12:49:26 AM UTC-4, Lennart Regebro wrote:

    On Wed, Jul 29, 2015 at six forty-two AM, Matthias Bussonnier
    < Bussonnie ... @ gmail.com <javascript:> > wrote:
    Hi,

    For whatever reason Strangely That make me 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 Flexibility in more playing
    with the API, like Delorean in [1] for example.
    Two datetime modules with different API is definitely not a good idea.
    I do think a new module is Necessary, but it shouldnt 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
    ______________________________ _________________
    Python-ideas mailing list Python ... @ Python.org <javascript:>Https://mail.python.org/
    <https://mail.python.org/mailman/listinfo/python-ideas>mailman / Listinfo
    / python-ideas <https://mail.python.org/mailman/listinfo/python-ideas>
    Code of Conduct: Http://python.org/psf/
    <http://python.org/psf/codeofconduct/>Codeofconduct /
    <http://python.org/psf/codeofconduct/>
    <javascript:>
    <https://mail.python.org/mailman/listinfo/python-ideas>
    <http://python.org/psf/codeofconduct/>
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150729/95bde165/attachment.html>

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-ideas @
categoriespython
postedJul 28, '15 at 8:10p
activeJul 29, '15 at 6:08p
posts11
users7
websitepython.org

People

Translate

site design / logo © 2018 Grokbase