Re: Improving datetime

Discussion in 'Python' started by Nicholas F. Fabry, Mar 19, 2008.

  1. On Mar 19, 2008, at 16:30, Christian Heimes wrote:

    > Nicholas F. Fabry schrieb:
    >> This is a query for information as to how to proceed. I am not a
    >> professional programmer, but I use Python a great deal to help me
    >> in my main job, which involves designing schedules for a global
    >> airline. As such, I use datetime (and dateutil) extensively, and
    >> after much use, I have come to some conclusions about their
    >> utility, and how to improve them. Some of these changes are quite
    >> minor and would result in a large increase in utility (low hanging
    >> fruit), while some changes are major, and would result in less
    >> obvious benefits - but these changes would increase the 'Python
    >> Zen' of them.
    >> So - where should I propose these changes? Here? python-dev?
    >> Should I write up a full PEP or should I just give a more informal
    >> outline with code samples? I would volunteer to help maintain/
    >> improve datetime, but I don't speak C at all, unfortunately, and
    >> datetime appears to be in C.

    >
    > Please write a detailed but not too long proposal to the Python
    > ideas mailing list. The proposal should explain how you like to
    > improve the datetime module. But *please* don't write a novel.
    > You'll get more attention when the signal to noise ratio is high. A
    > bullet list of features is easier to read than a long text block.
    >


    Thank you for the prompt response and suggestion! I am writing up a
    proposal presently. There are, however, two broad category of changes
    - the 'easy' changes, which could be accomplished with little
    additional effort, and the 'hard' changes, which would require
    significant reworking of the datetime class (or a wrapper around it).
    I was going to break my proposal up into two parts, the easy part and
    the hard part. Does that sound like a good idea? Or should I unify
    the two? The prime purpose of all the changes, easy and hard, is to
    make timezone handling accurate and clear, reduce and make clearer the
    (application programmer) code required to use them, and give more
    informaton to the programmer about errors, not silently assume
    something and pass them.

    I have to sign up for that mailing list - I will do so, and submit my
    ideas there.

    Please clarify how long a novel is? The problem with the modules are
    not bugs, they are problems with real world use scenarios that result
    in inescabably ugly code without improvements to the module - so the
    explanations involve code samples and use cases... so they may be
    'long'. Could you suggest a maximum number of (70 char) lines, or an
    example of an overly long proposal?


    > I'm a core developer and I may be interested in mentoring your
    > proposal. I can guide you through the process, review code and
    > commit it.
    >


    Thank you very much for the offer - I greatly appreciate it. I must
    admit, my motivation is because Python made programming so much fun
    for me again (my first machine was a Sinclair ZX80, long, long ago),
    and I want to improve this part of the language so datetime
    calculations are clean and neat (like the rest of Python) and don't
    force programmers to manually go through what the library should do
    for them.


    > Yes, the datetime module is written in C. But we may move the C code
    > to _datetime and create a facade module in Python.
    >


    That would be excellent for me, because the underlying datetime
    routines work correctly and quickly; it's the 'topmost' layer that
    needs to be improved to do the right thing. And, I could then
    actually write/maintain the Python code in the facade module, rather
    than request someone else 'do it for me' in C.

    To summarize my proposal VERY briefly:


    - Make aware datetime objects display in local time, but calculate/
    compare in UTC.

    - Raise exceptions when an illegal or ambiguous datetime is instantated.


    Thank you again,

    Nick






    > Christian
     
    Nicholas F. Fabry, Mar 19, 2008
    #1
    1. Advertising

  2. On Wed, 19 Mar 2008 17:40:39 -0400, Nicholas F. Fabry wrote:

    > To summarize my proposal VERY briefly:
    >
    >
    > - Make aware datetime objects display in local time, but calculate/
    > compare in UTC.


    Your proposal is ambiguous. What does that mean? Can you give an example?




    > - Raise exceptions when an illegal or ambiguous datetime is instantated.


    You mean like they already do?

    >>> datetime.datetime(2008, 03, 35) # 35th of March

    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    ValueError: day is out of range for month




    As for ambiguous, how can datetime arguments be ambiguous?

    Help on class datetime in module datetime:

    class datetime(date)
    | datetime(year, month, day[, hour[, minute[, second[,
    microsecond[,tzinfo]]]]])


    What possible ambiguity is there?


    --
    Steven
     
    Steven D'Aprano, Mar 19, 2008
    #2
    1. Advertising

  3. Nicholas F. Fabry

    Guest

    On Mar 19, 5:32 pm, Steven D'Aprano <st...@REMOVE-THIS-
    cybersource.com.au> wrote:
    > On Wed, 19 Mar 2008 17:40:39 -0400, Nicholas F. Fabry wrote:
    > > To summarize my proposal VERY briefly:

    >
    > > - Make aware datetime objects display in local time, but calculate/
    > > compare in UTC.

    >
    > What possible ambiguity is there?


    I agree.

    >>> D.datetime( 2008, 3, 23 )

    datetime.datetime(2008, 3, 23, 0, 0)
    >>> a=_
    >>> D.timedelta( minutes= 30, seconds= 80 )

    datetime.timedelta(0, 1880)
    >>> b= _
    >>> a+b

    datetime.datetime(2008, 3, 23, 0, 31, 20)
    >>> a+b-a

    datetime.timedelta(0, 1880)
     
    , Mar 21, 2008
    #3
  4. Nicholas F. Fabry wrote:
    > On Mar 19, 2008, at 16:30, Christian Heimes wrote:
    >
    >> Nicholas F. Fabry schrieb:
    >>> This is a query for information as to how to proceed. I am not a
    >>> professional programmer, but I use Python a great deal to help me in
    >>> my main job, which involves designing schedules for a global
    >>> airline. As such, I use datetime (and dateutil) extensively, and
    >>> after much use, I have come to some conclusions about their utility,
    >>> and how to improve them. Some of these changes are quite minor and
    >>> would result in a large increase in utility (low hanging fruit),
    >>> while some changes are major, and would result in less obvious
    >>> benefits - but these changes would increase the 'Python Zen' of them.
    >>> So - where should I propose these changes? Here? python-dev?
    >>> Should I write up a full PEP or should I just give a more informal
    >>> outline with code samples? I would volunteer to help
    >>> maintain/improve datetime, but I don't speak C at all,
    >>> unfortunately, and datetime appears to be in C.

    >>
    >> Please write a detailed but not too long proposal to the Python ideas
    >> mailing list. The proposal should explain how you like to improve the
    >> datetime module. But *please* don't write a novel. You'll get more
    >> attention when the signal to noise ratio is high. A bullet list of
    >> features is easier to read than a long text block.
    >>

    >
    > Thank you for the prompt response and suggestion! I am writing up a
    > proposal presently. There are, however, two broad category of changes -
    > the 'easy' changes, which could be accomplished with little additional
    > effort, and the 'hard' changes, which would require significant
    > reworking of the datetime class (or a wrapper around it). I was going
    > to break my proposal up into two parts, the easy part and the hard
    > part. Does that sound like a good idea? Or should I unify the two?
    > The prime purpose of all the changes, easy and hard, is to make timezone
    > handling accurate and clear, reduce and make clearer the (application
    > programmer) code required to use them, and give more informaton to the
    > programmer about errors, not silently assume something and pass them.
    >
    > I have to sign up for that mailing list - I will do so, and submit my
    > ideas there.
    >
    > Please clarify how long a novel is? The problem with the modules are
    > not bugs, they are problems with real world use scenarios that result in
    > inescabably ugly code without improvements to the module - so the
    > explanations involve code samples and use cases... so they may be
    > 'long'. Could you suggest a maximum number of (70 char) lines, or an
    > example of an overly long proposal?
    >
    >
    >> I'm a core developer and I may be interested in mentoring your
    >> proposal. I can guide you through the process, review code and commit it.
    >>

    >
    > Thank you very much for the offer - I greatly appreciate it. I must
    > admit, my motivation is because Python made programming so much fun for
    > me again (my first machine was a Sinclair ZX80, long, long ago), and I
    > want to improve this part of the language so datetime calculations are
    > clean and neat (like the rest of Python) and don't force programmers to
    > manually go through what the library should do for them.
    >
    >
    >> Yes, the datetime module is written in C. But we may move the C code
    >> to _datetime and create a facade module in Python.
    >>

    >
    > That would be excellent for me, because the underlying datetime routines
    > work correctly and quickly; it's the 'topmost' layer that needs to be
    > improved to do the right thing. And, I could then actually
    > write/maintain the Python code in the facade module, rather than request
    > someone else 'do it for me' in C.
    >
    > To summarize my proposal VERY briefly:
    >
    >
    > - Make aware datetime objects display in local time, but
    > calculate/compare in UTC.
    >
    > - Raise exceptions when an illegal or ambiguous datetime is instantated.
    >
    >
    > Thank you again,
    >
    > Nick
    >
    >
    >
    >
    >
    >
    >> Christian

    Nick,

    You might consider adding the Julian
    date
    (http://en.wikipedia.org/wiki/Julian_date).

    I had a crack at this a while ago but
    didn't seem to get quire the right
    result, using the ACM algorithm. I
    seemed to be a day out at the BC/AD divide.

    Colin W.
    >
     
    Colin J. Williams, Mar 21, 2008
    #4
  5. Nicholas F. Fabry wrote:
    > On Mar 19, 2008, at 16:30, Christian Heimes wrote:
    >
    >> Nicholas F. Fabry schrieb:
    >>> This is a query for information as to how to proceed. I am not a
    >>> professional programmer, but I use Python a great deal to help me in
    >>> my main job, which involves designing schedules for a global
    >>> airline. As such, I use datetime (and dateutil) extensively, and
    >>> after much use, I have come to some conclusions about their utility,
    >>> and how to improve them. Some of these changes are quite minor and
    >>> would result in a large increase in utility (low hanging fruit),
    >>> while some changes are major, and would result in less obvious
    >>> benefits - but these changes would increase the 'Python Zen' of them.
    >>> So - where should I propose these changes? Here? python-dev?
    >>> Should I write up a full PEP or should I just give a more informal
    >>> outline with code samples? I would volunteer to help
    >>> maintain/improve datetime, but I don't speak C at all,
    >>> unfortunately, and datetime appears to be in C.

    >>
    >> Please write a detailed but not too long proposal to the Python ideas
    >> mailing list. The proposal should explain how you like to improve the
    >> datetime module. But *please* don't write a novel. You'll get more
    >> attention when the signal to noise ratio is high. A bullet list of
    >> features is easier to read than a long text block.
    >>

    >
    > Thank you for the prompt response and suggestion! I am writing up a
    > proposal presently. There are, however, two broad category of changes -
    > the 'easy' changes, which could be accomplished with little additional
    > effort, and the 'hard' changes, which would require significant
    > reworking of the datetime class (or a wrapper around it). I was going
    > to break my proposal up into two parts, the easy part and the hard
    > part. Does that sound like a good idea? Or should I unify the two?
    > The prime purpose of all the changes, easy and hard, is to make timezone
    > handling accurate and clear, reduce and make clearer the (application
    > programmer) code required to use them, and give more informaton to the
    > programmer about errors, not silently assume something and pass them.
    >
    > I have to sign up for that mailing list - I will do so, and submit my
    > ideas there.
    >
    > Please clarify how long a novel is? The problem with the modules are
    > not bugs, they are problems with real world use scenarios that result in
    > inescabably ugly code without improvements to the module - so the
    > explanations involve code samples and use cases... so they may be
    > 'long'. Could you suggest a maximum number of (70 char) lines, or an
    > example of an overly long proposal?
    >
    >
    >> I'm a core developer and I may be interested in mentoring your
    >> proposal. I can guide you through the process, review code and commit it.
    >>

    >
    > Thank you very much for the offer - I greatly appreciate it. I must
    > admit, my motivation is because Python made programming so much fun for
    > me again (my first machine was a Sinclair ZX80, long, long ago), and I
    > want to improve this part of the language so datetime calculations are
    > clean and neat (like the rest of Python) and don't force programmers to
    > manually go through what the library should do for them.
    >
    >
    >> Yes, the datetime module is written in C. But we may move the C code
    >> to _datetime and create a facade module in Python.
    >>

    >
    > That would be excellent for me, because the underlying datetime routines
    > work correctly and quickly; it's the 'topmost' layer that needs to be
    > improved to do the right thing. And, I could then actually
    > write/maintain the Python code in the facade module, rather than request
    > someone else 'do it for me' in C.
    >
    > To summarize my proposal VERY briefly:
    >
    >
    > - Make aware datetime objects display in local time, but
    > calculate/compare in UTC.
    >
    > - Raise exceptions when an illegal or ambiguous datetime is instantated.
    >
    >
    > Thank you again,
    >
    > Nick
    >
    >
    >
    >
    >
    >
    >> Christian

    Nick,

    You might consider adding the Julian
    date
    (http://en.wikipedia.org/wiki/Julian_date).

    I had a crack at this a while ago but
    didn't seem to get quire the right
    result, using the ACM algorithm. I
    seemed to be a day out at the BC/AD divide.

    Colin W.
    >
     
    Colin J. Williams, Mar 21, 2008
    #5
  6. Nicholas F. Fabry

    Aahz Guest

    In article <>,
    Nicholas F. Fabry <> wrote:
    >
    >Please clarify how long a novel is? The problem with the modules are
    >not bugs, they are problems with real world use scenarios that result
    >in inescabably ugly code without improvements to the module - so the
    >explanations involve code samples and use cases... so they may be
    >'long'. Could you suggest a maximum number of (70 char) lines, or an
    >example of an overly long proposal?


    I'd suggest starting with a simple example of a problem you see. You may
    well be up against a design constraint: the datetime module is intended
    to provide *simple* and reasonably robust handling. There doesn't seem
    to be a PEP, unfortunately, but you might want to look for the discussion
    history leading to the including of datetime.
    --
    Aahz () <*> http://www.pythoncraft.com/

    "It is easier to optimize correct code than to correct optimized code."
    --Bill Harlan
     
    Aahz, Mar 21, 2008
    #6
  7. Colin J. Williams schrieb:
    > You might consider adding the Julian date
    > (http://en.wikipedia.org/wiki/Julian_date).
    >
    > I had a crack at this a while ago but didn't seem to get quire the right
    > result, using the ACM algorithm. I seemed to be a day out at the BC/AD
    > divide.


    Yes, the Julian date family is very useful when dealing with dates
    before 1900. I'm +1 for adding JDT and MJD.

    TAI64 is another time format used for high precision and real time
    measurement. http://cr.yp.to/libtai/tai64.html

    Christian
     
    Christian Heimes, Mar 21, 2008
    #7
  8. On Mar 21, 2008, at 13:36, Christian Heimes wrote:

    > Colin J. Williams schrieb:
    >> You might consider adding the Julian date
    >> (http://en.wikipedia.org/wiki/Julian_date).
    >>
    >> I had a crack at this a while ago but didn't seem to get quire the
    >> right
    >> result, using the ACM algorithm. I seemed to be a day out at the
    >> BC/AD
    >> divide.

    >
    > Yes, the Julian date family is very useful when dealing with dates
    > before 1900. I'm +1 for adding JDT and MJD.
    >
    > TAI64 is another time format used for high precision and real time
    > measurement. http://cr.yp.to/libtai/tai64.html
    >


    This is that 'feature creep' thing I keep reading about on Dilbert,
    eh? ;-)

    Obviously, this would not be considered an 'easy bit' - however, the
    basic datetime.datetime class needs overhauling anyway when we get to
    the harder bits. So, it's worth determining whether we just want to
    have it run in the proleptic Gregorian calendar (ISO 8601), or figure
    out other calendars as well. I don't know anything about TAI64, but
    I'll read about it. The Julian I do know about (rioting after
    'losing' 10 days? Sheesh!) - it was a pretty reasonable swag at
    hitting the solar year for its time....


    <wild speculations>
    Perhaps it might be wise to consider a 'calendar definition object' -
    I'll dub it a calinfo object for now - that allows third parties to
    develop a set of rules that define a) how to count in a calendar, and
    b) how to translate unambiguously from one calendar to another. This
    suggests that we need a 'standard' calendar, much like UTC is the
    default timezone for calculations; the proleptic Gregorian seems like
    the obvious choice for now.

    So, a new 'superaware' datetime object represents a moment in time and
    would have:

    a local datetime, representing what 'local' clocks and calendar
    indicate at that time
    a UTC datetime, representing what UTC clocks and calendar indicate at
    that time
    a tzinfo object, encapsulating the the rules for translating local
    times to/from UTC, and
    a calinfo object, encapsulating:
    the calculation rules for adding & subtracting timedeltas to datetimes
    the calculation rules for finding the timedelta between two datetimes
    the translation rules for converting a datetime with a calinfo object
    into a datetime with a 'standard' calinfo object

    With time zones, because their offsets regularly swing back and forth,
    we have issues with illegal and ambiguous local times. I don't know
    much about different calendars - I am somewhat sure for Gregorian <-->
    Julian there are no ambiguities or 'illegal' dates, but I don't know
    about other calendars.

    I haven't thought of this before. I need to mull over how to do this
    - if we are going to spend the time developing three different methods
    of calculations for three different calendars, and I know there are
    other calendar systems in the world, it strikes me that the forward
    thinking thing to do is figure out how to abstract the calendar rule
    concept, develop a few common examples, and leave it to others
    (initially) to develop other calendars, much as third parties
    implemented concrete tzinfo subclasses. In doing so, they revealed
    some of the present limitations with the current implementation of
    datetime, that we are now considering updating. We may not have
    enough experience here of other calendar systems to get this totally
    right on the first go round, but it sounds worth a try....
    </wild speculations>


    > Christian
    >


    P.S. By Stewart, I assume you mean the author of pytz? And I think I
    got the 'no novel' concept - write for people who understand the basic
    ideas already. Have a good weekend!

    Nick







    > --
    > http://mail.python.org/mailman/listinfo/python-list
     
    Nicholas F. Fabry, Mar 22, 2008
    #8
  9. Nicholas F. Fabry

    John Machin Guest

    On Mar 22, 4:36 am, Christian Heimes <> wrote:
    > Colin J. Williams schrieb:
    >
    > > You might consider adding the Julian date
    > > (http://en.wikipedia.org/wiki/Julian_date).

    >
    > > I had a crack at this a while ago but didn't seem to get quire the right
    > > result, using the ACM algorithm. I seemed to be a day out at the BC/AD
    > > divide.


    1. Somewhere in the Colin-Christian-Nicholas thread, the "Julian date"
    and the "Julian calendar" seem to become conflated.
    2. "day out": possibly because there is no year 0; year 1 BCE is
    followed immediately by year 1 CE.

    >
    > Yes, the Julian date family is very useful when dealing with dates
    > before 1900.


    I'm having some difficulty understanding the above sentence, given
    either interpretation of "Julian date family". What is the
    significance of 1900?

    [Julian calendar interpretation] Some countries (including Russia,
    China, Greece and Turkey) did not adopt the Gregorian calendar until
    after 1900. Dealing with a date expressed as (year, month, day) is far
    from easy for approx year range 1582 to 1926 unless it has been
    expressly tagged as e.g. "old style" or "new style". If so tagged,
    there is to me no difference in ease of use between the proleptic
    Julian calendar and the proleptic Gregorian calendar.

    [Julian date as used in astronomy] This supports dates back to about
    4800 BCE easily, whereas Python's datetime module supports the
    proleptic Gregorian calendar only back to year 1 CE.

    Cheers,
    John
     
    John Machin, Mar 22, 2008
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Christos TZOTZIOY Georgiou
    Replies:
    3
    Views:
    732
    Christos TZOTZIOY Georgiou
    Sep 13, 2003
  2. Tim Peters
    Replies:
    0
    Views:
    555
    Tim Peters
    Sep 9, 2003
  3. mp
    Replies:
    1
    Views:
    402
    John Machin
    Jul 28, 2006
  4. Martin
    Replies:
    0
    Views:
    350
    Martin
    Dec 27, 2008
  5. Replies:
    2
    Views:
    774
    M.-A. Lemburg
    Jan 6, 2009
Loading...

Share This Page