Re: time, calendar, datetime, etc

Discussion in 'Python' started by Ben S, Jul 31, 2003.

  1. Ben S

    Ben S Guest

    Skip Montanaro wrote:
    > kylotan> Is there any chance of these modules becoming somewhat
    > combined kylotan> in the future?
    >
    > Maybe. Perhaps you would like to write a PEP?


    I would think that is best left up to those who know what they're
    doing... I'm just a newbie who's found date and time handling in Python
    to be confusing, and thought I'd mention it. (And I am the original
    poster, btw.) If nobody else agrees, maybe it's not really a problem.

    > kylotan> Right now it seems a little awkward to find the function
    > you kylotan> want. The main culprit is 'timegm' which is the only
    > thing I kylotan> need from the calendar module but which should
    > probably be in kylotan> the time module.
    >
    > I've never used it, but it looks like you're right. It's the GMT/UTC
    > equivalent of time.mktime(), right?


    Possibly... I am not intimately familiar with all the different
    functions. It would help if there was some sort of table in the docs
    that laid the various time functions side by side for an easy
    comparison.

    > kylotan> PS. I use 'time.strptime(myTime, '%a %b %d %H:%M:%S
    > %Y')' as a kylotan> reverse-asctime(), and was surprised that I
    > couldn't find this kylotan> wrapped in a function in any of the
    > modules. Maybe such a kylotan> function would be considered for
    > future addition?
    >
    > Seems simple enough to not be needed. What makes asctime() all that
    > special?


    Well, one could say that its very existence makes it special.
    Technically asctime() is redundant as you can achieve the same effect
    with time.strftime(). Yet it's in the library. Since time.asctime()
    exists as a special case, we're assuming that the use of that particular
    string format has some intrinsic merit. In particular, a lot of programs
    written in C may use it for logfiles. Therefore it makes sense (to me)
    to implement the inverse ("timeasc"?).

    --
    Ben Sizer
    http://pages.eidosnet.co.uk/kylotan
    Ben S, Jul 31, 2003
    #1
    1. Advertising


  2. >> Maybe. Perhaps you would like to write a PEP?


    Ben> I would think that is best left up to those who know what they're
    Ben> doing... I'm just a newbie who's found date and time handling in
    Ben> Python to be confusing, and thought I'd mention it. (And I am the
    Ben> original poster, btw.) If nobody else agrees, maybe it's not
    Ben> really a problem.

    Yeah, but you spoke up. ;-) There are probably lots of people willing to
    throw stones at^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hcomment on your work, and since
    this would largely be a reorganization of existing modules, there wouldn't
    be all that much Python knowledge required (except that backwards
    compatibility is a requirement for 2.4). In any case, if you have concrete
    ideas about how the three should be merged into two, a PEP's the best place
    to document it. Your ideas will largely be lost if the python-list archive
    is the only place they are recorded.

    Ben> Well, one could say that its very existence makes it special.
    Ben> Technically asctime() is redundant as you can achieve the same
    Ben> effect with time.strftime().

    I believe asctime() predates strftime() as a C library function by quite a
    bit.

    Ben> Yet it's in the library. Since time.asctime() exists as a special
    Ben> case, we're assuming that the use of that particular string format
    Ben> has some intrinsic merit. In particular, a lot of programs written
    Ben> in C may use it for logfiles. Therefore it makes sense (to me) to
    Ben> implement the inverse ("timeasc"?).

    I couldn't pick an asctime()-generated date out of a lineup. For most
    logging I think it makes sense to use sortable numeric dates (ISO-8601).
    Besides sortability, they are indifferent to language and unambiguous.
    There are many little variations in "human readable" dates, even those which
    are so-called standards. Someone always gets things "wrong". Quick, what's
    the format of an RFC-822 date? Is it the same as an RFC-2822 date? What
    about RFC-1036? RFC-850?

    Not that I have any claim to have been complaining loud and clear about this
    problem back in 1982 and 1983 when these RFC were written (or earlier, when
    the systems they codified were first developed), but I don't think there's
    any use in further propagating arcane date formats.

    Skip
    Skip Montanaro, Jul 31, 2003
    #2
    1. Advertising

  3. Ben S

    John Roth Guest

    "Skip Montanaro" <> wrote in message
    news:...
    >


    >
    > I couldn't pick an asctime()-generated date out of a lineup. For most
    > logging I think it makes sense to use sortable numeric dates (ISO-8601).
    > Besides sortability, they are indifferent to language and unambiguous.
    > There are many little variations in "human readable" dates, even those

    which
    > are so-called standards. Someone always gets things "wrong". Quick,

    what's
    > the format of an RFC-822 date? Is it the same as an RFC-2822 date? What
    > about RFC-1036? RFC-850?
    >
    > Not that I have any claim to have been complaining loud and clear about

    this
    > problem back in 1982 and 1983 when these RFC were written (or earlier,

    when
    > the systems they codified were first developed), but I don't think there's
    > any use in further propagating arcane date formats.


    Amen, brother!

    John Roth
    >
    > Skip
    >
    >
    John Roth, Jul 31, 2003
    #3
  4. Ben S

    John Roth Guest

    "A.M. Kuchling" <> wrote in message
    news:...
    > On Thu, 31 Jul 2003 08:06:29 -0500,
    > Skip Montanaro <> quoted:
    > > Ben> doing... I'm just a newbie who's found date and time handling

    in
    > > Ben> Python to be confusing, and thought I'd mention it. (And I am

    the
    > > Ben> original poster, btw.) If nobody else agrees, maybe it's not
    > > Ben> really a problem.

    >
    > It's also not very hard to write a PEP; start with an existing PEP for the
    > headings, and skim PEP 1 for the PEP life cycle.
    >
    > Parsing of date/time formats is the big omission from 2.3's date support

    and
    > the big advantage that mxDateTime still has. With 2.3 you still have to
    > roll your own parser for ISO-8601 format or whatever. Fixing the rfc822
    > module is probably the largest problem; we can't just change getdate() to
    > return a datetime instead of a 9-tuple, so it'll have to be supported as a
    > new method. The standard library should probably use datetime as much as
    > possible, but backwards-compatible 9-tuple-based interfaces will still

    need
    > to be supported.


    The datetime module is a great piece of work, but I wonder why it
    wasn't made more compatible with the time module? It would seem to
    be simple enough to provide a sequence interface so the object
    supports the 9-tuple directly (for either naive or tz-aware, pick one,)
    and also supports the same attributes as the objects in the time package.

    I also wonder why anyone made the choice to set the year origin at
    1AD? That decision, by itself, makes it almost unusable for my hobby
    (astrological software, which is basically astronomical software
    with a different focus.) Astronomical dates are always measured
    in days since 4700 and something BC. History did not begin, after
    all, six years after JC was born. (And astronomical years, btw,
    do include a year zero, which historical years do not.)

    Other than that, and a couple of other bobbles (depending on the
    C library for strftime(), and the lack of an input parser both come
    to mind) it's a great piece of work.

    John Roth


    >
    > --amk (www.amk.ca)
    > Hello! I'm the Doctor. I believe you want to kill me.
    > -- The Doctor, in "Silver Nemesis"
    John Roth, Jul 31, 2003
    #4
  5. Ben S

    Andrew Dalke Guest

    John Roth:
    > I also wonder why anyone made the choice to set the year origin at
    > 1AD? That decision, by itself, makes it almost unusable for my hobby
    > (astrological software, which is basically astronomical software
    > with a different focus.) Astronomical dates are always measured
    > in days since 4700 and something BC.


    Well, if you're doing astronomical time, wouldn't you just add 4700
    and something years and 12 hours (as I recall, astronomers have a
    12 hours offset because they observe at night and don't want to have
    to change the date (or forget to change the date) part way though.)
    How is that unusable?

    Why would supporing you be reasonable to the other 99+% of the
    users who don't care about doing astronomical measurements, nor
    even about the "was there a year 0?" debate.

    And as for unusable, bah. The nuances of time are very sublte.
    Ivan Van Laningham at the Houston conference ('98, I think) gave
    a paper on using Python for the Mayan calendar. Even if Python
    were to use astronomical time as its basis, that code wouldn't handle
    his needs - eg, he wanted to know when the Mayan calendar repeats
    itself. Answer? Once every
    2549465048574470321568539870223503965392934390771449170872386445565969718817
    5919250180245133376000
    years. His paper is at
    http://www.foretec.com/python/workshops/1998-11/proceedings/papers/laningham
    /laningham.html
    and it was a very enjoyable talk.

    For another example, to be really precise, a datetime module needs
    to support leap seconds, so that "23:59:60" is, at times, valid. But
    Python's datetime module doesn't allow that.

    And if it did, it would almost certainly break code written by people
    who didn't know there could be 61 seconds in a minute.

    So in summary, almost no one needs the functionality beyond what
    the standard library has, supporting each and every specialized niche
    makes for more complex code, and more complex code means people
    who do "normal" programming are much more likely to run into problems
    and make the code more likely to break.

    Andrew
    Andrew Dalke, Aug 1, 2003
    #5
  6. John Roth wrote:
    > The datetime module is a great piece of work, but I wonder why it
    > wasn't made more compatible with the time module? It would seem to
    > be simple enough to provide a sequence interface so the object
    > supports the 9-tuple directly (for either naive or tz-aware, pick one,)
    > and also supports the same attributes as the objects in the time package.
    >
    > I also wonder why anyone made the choice to set the year origin at
    > 1AD? That decision, by itself, makes it almost unusable for my hobby
    > (astrological software, which is basically astronomical software
    > with a different focus.) Astronomical dates are always measured
    > in days since 4700 and something BC. History did not begin, after
    > all, six years after JC was born. (And astronomical years, btw,
    > do include a year zero, which historical years do not.)


    FWIW, mxDateTime has all needed features for these things (and has
    had them for years).

    --
    Marc-Andre Lemburg
    eGenix.com

    Professional Python Software directly from the Source (#1, Aug 01 2003)
    >>> Python/Zope Products & Consulting ... http://www.egenix.com/
    >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

    ________________________________________________________________________
    M.-A. Lemburg, Aug 1, 2003
    #6
  7. Ben S

    Ben Finney Guest

    On Thu, 31 Jul 2003 22:47:27 -0600, Andrew Dalke wrote:
    > Why would supporing you be reasonable to the other 99+% of the
    > users who don't care about doing astronomical measurements


    It is astronomy (and, before it, astrology) that has driven the
    standardisation of time for many centuries; anyone wanting to use a
    standardised time system is using one based on astronomical imperatives.

    > even about the "was there a year 0?" debate.


    Anyone who wants to deal with dates BC (in the Gregorian calendar) cares
    about the "was there a year 0?" question (answer: not in the Gregorian
    calendar, there wasn't).

    So it seems you're dismissing a large sector of users: those who deal
    with dates before 1AD, and those who want to use worldwide date/time
    standards.

    > Python's datetime module doesn't allow [more than 60 seconds in a
    > minute].
    > And if it did, it would almost certainly break code written by people
    > who didn't know there could be 61 seconds in a minute.


    Such people would run into trouble when leap seconds occurred anyway;
    keeping the datetime module ignorant of it just means the problems will
    not be dealt with when the program is designed (when it is easy to
    correct) but rather be thrust in their face when a leap second occurs
    (presumably when the program has been long forgotten about and the
    original programmer possibly departed).

    > So in summary, almost no one needs the functionality beyond what the
    > standard library has, supporting each and every specialized niche
    > makes for more complex code, and more complex code means people who do
    > "normal" programming are much more likely to run into problems and
    > make the code more likely to break.


    Quite the reverse. If the standard library supported things like leap
    seconds, absence-of-year-zero, and Julian dates, it would be wrapped up
    in one place where programmers could use it without having to know about
    the implementation complexities.

    --
    \ "Anything that is too stupid to be spoken is sung." -- Voltaire |
    `\ |
    _o__) |
    Ben Finney <http://bignose.squidly.org/>
    Ben Finney, Aug 1, 2003
    #7
  8. Ben S

    John Roth Guest

    "Andrew Dalke" <> wrote in message
    news:bgcr5a$8ac$...
    > John Roth:
    > > I also wonder why anyone made the choice to set the year origin at
    > > 1AD? That decision, by itself, makes it almost unusable for my hobby
    > > (astrological software, which is basically astronomical software
    > > with a different focus.) Astronomical dates are always measured
    > > in days since 4700 and something BC.

    >
    > Well, if you're doing astronomical time, wouldn't you just add 4700
    > and something years and 12 hours (as I recall, astronomers have a
    > 12 hours offset because they observe at night and don't want to have
    > to change the date (or forget to change the date) part way though.)
    > How is that unusable?


    Because I need to be able to deal with BC dates, obviously. Fudging
    the base date won't handle that.

    > Why would supporing you be reasonable to the other 99+% of the
    > users who don't care about doing astronomical measurements, nor
    > even about the "was there a year 0?" debate.


    Mostly because I don't see a particular reason for the actual
    decision tha was reached.

    > And as for unusable, bah. The nuances of time are very sublte.
    > Ivan Van Laningham at the Houston conference ('98, I think) gave
    > a paper on using Python for the Mayan calendar. Even if Python
    > were to use astronomical time as its basis, that code wouldn't handle
    > his needs - eg, he wanted to know when the Mayan calendar repeats
    > itself. Answer? Once every
    >

    2549465048574470321568539870223503965392934390771449170872386445565969718817
    > 5919250180245133376000
    > years. His paper is at
    >

    http://www.foretec.com/python/workshops/1998-11/proceedings/papers/laningham
    > /laningham.html
    > and it was a very enjoyable talk.


    There are a number of "Mayan" calendars; it's a very complicated
    subject. I had no objection to using the proleptic Gregorian calendar
    for display: you have to use something, and that's almost universally
    used. If you do any kind of historical research, you suddenly discover
    that what you thought you knew about dates doesn't work in practice,
    even in Western Europe. This is why astronomical dating is important:
    it provides a single, well understood and accepted dating system that
    can be tied to the (unfortunatelly rare) comments about astronomical
    phenomena, and it goes back far enough that all dates of historical
    interest are positive numbers.

    >
    > For another example, to be really precise, a datetime module needs
    > to support leap seconds, so that "23:59:60" is, at times, valid. But
    > Python's datetime module doesn't allow that.


    Usually, that's handled by a separate conversion from UT (Universal
    Time) to ET (Ephemeris time.) And leap seconds are a modern innovation:
    for accuracy there are a number of correction formulae that you apply
    depending on the exact historical era in question.
    >
    > And if it did, it would almost certainly break code written by people
    > who didn't know there could be 61 seconds in a minute.


    Funny about that: the Unix system specifications that I've seen
    have always said that there may be 61 seconds in a minute. It's built
    into the API.

    > So in summary, almost no one needs the functionality beyond what
    > the standard library has, supporting each and every specialized niche
    > makes for more complex code, and more complex code means people
    > who do "normal" programming are much more likely to run into problems
    > and make the code more likely to break.


    Andrew, you've brought in an army of straw men. The **ONLY**
    thing I was criticising was the decision to limit the module to dates
    beginning with 1 AD. All the other things you bring up are things that
    I either don't care about, or that I agree shouldn't complicate the API.

    John Roth
    >
    > Andrew
    >
    >
    >
    John Roth, Aug 1, 2003
    #8
  9. Ben S

    John Roth Guest

    "Christopher Koppler" <> wrote in message
    news:...
    > On Thu, 31 Jul 2003 22:49:28 -0400, "Tim Peters" <>
    > wrote:
    >
    > >The time module consists of thin wrappers around C's mish-mash of quirky,
    > >platform-dependent time manipulation functions. We eventually want to
    > >pretend the time module never existed <0.9 wink>. 9-tuples are absurd.

    >
    > No, it's reality that's absurd. C's mish-mash of quirky,
    > platform-dependent time manipulation stems from the fact that defining
    > a standard way of handling time is difficult when it's
    > 1. subject to the platform designers interpretation of what is useful,
    > 2. subject to politics and most severely,
    > 3. subject to changes in nature.
    >
    > Leap seconds!


    Frankly, if what was wanted was a single, consistent and usable
    definition of time, the astronomical Julian date is it. It's a single
    number,
    absolutely continuous since 4712 BC or thereabouts, and has well
    defined conversions to and from the proleptic Gregorian and Julian
    calendars. It takes me about two clicks to determine that the current
    AJD is 2452852.9650.

    Anything else is politics and poor analysis.

    The funny thing is, it wouldn't be all that hard to fix. The only
    part of the formal API that I can see which is even remotely
    affected is the fromordinal() method, and there's no reason to
    change it, just to define it as only being effective from 1AD
    onwards. All that's needed, really, is a constructor that takes
    the AJD, and an extraction method for it. Since the package
    doesn't have any string to date conversion routines (presumably
    yet,) not even that's affected.

    John Roth
    >
    >
    > --Christopher
    John Roth, Aug 1, 2003
    #9
  10. Ben S

    Andrew Dalke Guest

    Ben Finney:
    > It is astronomy (and, before it, astrology) that has driven the
    > standardisation of time for many centuries; anyone wanting to use a
    > standardised time system is using one based on astronomical imperatives.


    And here I thought it was the railroads which drove the standarization.
    Before then, each city had its own noon, and the only standarization
    between places was for dates. (Except also depending on your faith.)
    Granted, "noon" is an astronomical measurement, just that the actual
    time changed from place to place.

    Kinda depends on what you call "standard". And before trains,
    ships wanted to know the time to know the location, and monks
    wanted to know when to pray, and ..

    So again I say, most people don't care that much about the time.
    A useful library doesn't need to incorporate all the details needed by
    astronomers, historians, etc.

    > Anyone who wants to deal with dates BC (in the Gregorian calendar) cares
    > about the "was there a year 0?" question (answer: not in the Gregorian
    > calendar, there wasn't).
    >
    > So it seems you're dismissing a large sector of users: those who deal
    > with dates before 1AD, and those who want to use worldwide date/time
    > standards.


    That's not in disagreement with what I said. I said (though more
    loosely) 99+% of the people who are affected by the restrictions of
    datetime won't notice a problem. The remaining <1% might still be
    "a large sector of users". For them I say, develop a library which
    deals with all that complexity (or use the mx package).

    Python doesn't try to support all numerical systems - that's why
    Numeric exists. Would those users like Numeric support in core
    Python? Probably. Are there more Numeric users than people
    who need a detailed datetime library? Almost certainly yes. So
    I aks again, what makes datetime with B.C. support, leap seconds,
    etc. important enough to justify inclusion in Python's standard library.

    By comparison, a friend of mine mentioned that the Java time library,
    which does try to include all these complexities, has gone through
    several iterations to get where it is now and is complicated to use
    because it tries to get all the details right.

    > Such people would run into trouble when leap seconds occurred anyway;


    Ha! None of my code ever used leap seconds, and in my 15 years
    or so of software development, no one ever filed a bug report on it.
    And on the plus side, I don't have to distribute an update when there
    is an new leap second. That's because for just about everyone in the
    world, a difference of a few seconds doesn't make a difference.
    C'mon - the clocks in my house are +/- a few minutes!

    It's only the very small number of people who care about the differences
    between UTC, UT1, GPS, TAI, and all those other highly specialized
    time systems that care about these sorts of details ("care" == "affects
    them in any meaningful way"), so what's wrong with those people
    developing a specialized library to handle those issues?

    > keeping the datetime module ignorant of it just means the problems will
    > not be dealt with when the program is designed (when it is easy to
    > correct) but rather be thrust in their face when a leap second occurs
    > (presumably when the program has been long forgotten about and the
    > original programmer possibly departed).


    Easy to correct? Okay, the last leap second was added 1/1/99. Did
    you upgrade some data file then to include that change? Or did your
    software fix itself automatically? Or did you just synch your machine
    to network time and figure it was part of normal clock skew?


    > Quite the reverse. If the standard library supported things like leap
    > seconds, absence-of-year-zero, and Julian dates, it would be wrapped up
    > in one place where programmers could use it without having to know about
    > the implementation complexities.


    Implement that library, get people to use it, implement the functionality
    of the datetime module using it, make sure it's maintainable and
    maintained, petition for its inclusion in Python.

    Then again, you could just use mxDateTime.

    Here's another view of the issue. The datetime module implements what
    I'll call "vernacular" time. That is, time as is understood by most people.
    24 hours in a day, 60 minutes in an hour, 60 seconds in a day, 365 days
    in a year except every 4th year (and hazy idea about something strange
    at the century mark, but that's not a problem now). And then there's
    timezones and daylight savings time. (And no thoughts of "double
    daylight savings like the British had during WWII.")

    datetime implements vernacular time. There's a lot of code
    which implements vernacular time, because they aren't written
    by experts. To them, 1) datetime makes sense and 2) won't
    ever cause problems in real life.

    I am one of those people. I would like to replace my hand-written
    code with a standard library. I want that library to implement *my*
    time system, not the so-called real one developed by experts who
    worry about variations in the Earth's rotation nor about scholars
    who say the first day of the year back in 1000AD was in March.

    So a robust datetime library almost certainly must implement
    this vernacular time system, if only for completeness. Consider
    'datetime' as the first module for that hypothetical library. It
    definitely is useful as-is. Now we just have to wait for the rest
    of it to be implemented.

    Ahhh, I shoulda been a philosopher. :)

    Andrew
    Andrew Dalke, Aug 1, 2003
    #10
  11. Ben S

    Andrew Dalke Guest

    John Roth:
    > Because I need to be able to deal with BC dates, obviously. Fudging
    > the base date won't handle that.


    Ahhh, I see. I figured you just had dates in Julian, and algorithms
    for dealing with dates in Julian, so what you needed was the
    ability to deal with present dates (within a few decades at most)
    and not define some date in history.

    Just to point out though, before 2.3 you couldn't have used Python's
    libraries for that either, since the C epoch doesn't handle dates
    before 1970. Instead, you would have used mxDateTime, which
    does a good job at this, and still does.

    > > Why would supporing you be reasonable to the other 99+% of the
    > > users who don't care about doing astronomical measurements, nor
    > > even about the "was there a year 0?" debate.

    >
    > Mostly because I don't see a particular reason for the actual
    > decision tha was reached.


    To be complete, a datetime library needs to handle a *lot* of details.
    That makes the library hard to implement and maintain. Eg,
    what about the days that 'disappeared' between Julian and Gregorian,
    leap seconds, and other worries? Most people don't need that.
    For them and me, datetime is good enough. The datetime module
    needs a 0 point (the creation of the universe being rather long ago
    and the exact time not well known). Given the questions of "when
    is year 0?" in different calendar systems, it's easy for me to
    understand why Jan. 1st, 1AD is a good starting point. (Easier
    than Jan 1st, 1970 - I prefered the Mac's epoch of 1900.)

    > used. If you do any kind of historical research, you suddenly discover
    > that what you thought you knew about dates doesn't work in practice,
    > even in Western Europe.


    Well, I don't do historical research. I'm pretty insular that way. I
    know there are problems in interpreting dates - my religious training
    taught me that if nothing else.

    > This is why astronomical dating is important:
    > it provides a single, well understood and accepted dating system that
    > can be tied to the (unfortunatelly rare) comments about astronomical
    > phenomena, and it goes back far enough that all dates of historical
    > interest are positive numbers.


    Understood. I still maintain that a library which handles all the
    specialized datetime issues (historical, religious, astronomical,
    navigation, ...) is too complex for inclusion in Python's standard
    library. Specialists should use a specialist's library. What Python
    has is quite good enough for just about everyone's needs.

    Put it this way - FixedPoint still isn't part of Python's standard
    library even though it's very important for people dealing with
    money. Then again, for most people, floats (!) are good enough.

    > Usually, that's handled by a separate conversion from UT (Universal
    > Time) to ET (Ephemeris time.) And leap seconds are a modern innovation:
    > for accuracy there are a number of correction formulae that you apply
    > depending on the exact historical era in question.


    And it makes sense for Python's standard library to handle all
    that?

    > Funny about that: the Unix system specifications that I've seen
    > have always said that there may be 61 seconds in a minute. It's built
    > into the API.


    And there's where I learned it from. Doesn't mean the libraries
    support it. And I'm told the C spec's comment about "double leap
    seconds" is based on a misunderstanding and those don't actually exist.

    One of the reasons for Python to do it's own datetime code is because
    of the broken nature of many platforms native time functions.

    > Andrew, you've brought in an army of straw men. The **ONLY**
    > thing I was criticising was the decision to limit the module to dates
    > beginning with 1 AD. All the other things you bring up are things that
    > I either don't care about, or that I agree shouldn't complicate the API.


    Then you misunderstand my comments. You have a very specialized
    need to handle dates before 1AD. Others have a specialized need to
    handle leap seconds. Others need to deal with differences between
    UTC, UT1, GPS, and other time systems. Still others need to handle
    complicated timezones (like "double daylight savings", which I think
    datetime doesn't handle). Others again need better than microsecond
    timestamps. For all I know, some need a general relativity
    compensation term.

    To handle all of these and maintain them as the various time standards
    change requires effort. There aren't all that many people working
    on Python. They decided that most people only need what I termed
    'vernacular' time in a previous post in this thread, and that time
    system works for 99+% of the datetime needs in the world, and that's
    what they implemented. And I commend the developers for defining
    what "good enough" means, and defering perfection to other libraries
    and future inclusion. Very Pythonic.

    Andrew
    Andrew Dalke, Aug 1, 2003
    #11
  12. Ben S

    John Roth Guest

    "Andrew Dalke" <> wrote in message
    news:bgejrq$i54$...
    > Ben Finney:


    [...]

    > Python doesn't try to support all numerical systems - that's why
    > Numeric exists. Would those users like Numeric support in core
    > Python? Probably. Are there more Numeric users than people
    > who need a detailed datetime library? Almost certainly yes. So
    > I aks again, what makes datetime with B.C. support, leap seconds,
    > etc. important enough to justify inclusion in Python's standard library.
    >
    > By comparison, a friend of mine mentioned that the Java time library,
    > which does try to include all these complexities, has gone through
    > several iterations to get where it is now and is complicated to use
    > because it tries to get all the details right.


    Several turns out to be one revision, and I don't think that they
    got it right either. From what I see, the Python datetime library
    is actually more complicated than the Java library: it's certainly
    got more classes, although they seem to be better designed.

    >
    > > Such people would run into trouble when leap seconds occurred anyway;

    >
    > Ha! None of my code ever used leap seconds, and in my 15 years
    > or so of software development, no one ever filed a bug report on it.
    > And on the plus side, I don't have to distribute an update when there
    > is an new leap second. That's because for just about everyone in the
    > world, a difference of a few seconds doesn't make a difference.
    > C'mon - the clocks in my house are +/- a few minutes!


    For the most part, the applications that need to be aware of leap
    seconds are the ones that communicate with other servers that
    are aware of leap seconds, and can report them. As far as I'm
    aware, leap seconds are a thing of the past anyway: they proved
    to be more trouble than they were worth to anyone.

    > It's only the very small number of people who care about the differences
    > between UTC, UT1, GPS, TAI, and all those other highly specialized
    > time systems that care about these sorts of details ("care" == "affects
    > them in any meaningful way"), so what's wrong with those people
    > developing a specialized library to handle those issues?


    Nothing at all - I'd expect to see some sort of an extension to
    handle those issues, just as I'd expect to see an extension if you
    wanted to use the proleptic Julian calendar, the Chinese calendar,
    the civil Moslem calendar, the Jewish calendar, and on and on
    and on.

    I'd also expect to see some sort of reasonably well thought out framework
    where those extensions could simply be plugged in and just work.

    > > Quite the reverse. If the standard library supported things like leap
    > > seconds, absence-of-year-zero, and Julian dates, it would be wrapped up
    > > in one place where programmers could use it without having to know about
    > > the implementation complexities.

    >
    > Implement that library, get people to use it, implement the functionality
    > of the datetime module using it, make sure it's maintainable and
    > maintained, petition for its inclusion in Python.
    >
    > Then again, you could just use mxDateTime.
    >
    > Here's another view of the issue. The datetime module implements what
    > I'll call "vernacular" time. That is, time as is understood by most

    people.
    > 24 hours in a day, 60 minutes in an hour, 60 seconds in a day, 365 days
    > in a year except every 4th year (and hazy idea about something strange
    > at the century mark, but that's not a problem now). And then there's
    > timezones and daylight savings time. (And no thoughts of "double
    > daylight savings like the British had during WWII.")
    >
    > datetime implements vernacular time. There's a lot of code
    > which implements vernacular time, because they aren't written
    > by experts. To them, 1) datetime makes sense and 2) won't
    > ever cause problems in real life.
    >
    > I am one of those people. I would like to replace my hand-written
    > code with a standard library. I want that library to implement *my*
    > time system, not the so-called real one developed by experts who
    > worry about variations in the Earth's rotation nor about scholars
    > who say the first day of the year back in 1000AD was in March.


    Where was it in March? [grin]. Answer. It depends on where is.

    > So a robust datetime library almost certainly must implement
    > this vernacular time system, if only for completeness. Consider
    > 'datetime' as the first module for that hypothetical library. It
    > definitely is useful as-is. Now we just have to wait for the rest
    > of it to be implemented.


    I'm certainly not objecting to that. That's the interface to a time
    system that everyone expects, and other objectives should quite
    properly be implemented by some sort of extensions. My objection
    is to exactly one implementation decision: to limit the time range
    at 1AD. That is, to use the vernacular, a show-stopper. It means
    that the core of the library has to be reworked if you want to deal
    with dates before 1AD. It has nothing to do with the external
    interfaces, nor does it have anything to do with whether the package
    has the ability to use proleptic Julian dates, Chinese dates, Muslim
    civil calendar dates, or anything else.

    I don't have the time to look into how difficult it would be
    to change that. Right now, I'm working on bringing the Python
    version of FIT up to the March Java release, and integrating
    it with FitNesse. Maybe when I get back to my astrology
    programming. My application date package works for what
    I need it to do; it just seems that I can't abandon it for the
    standard Python library package. [Sigh.]

    John Roth

    >
    > Ahhh, I shoulda been a philosopher. :)
    >
    > Andrew
    >
    >
    >
    John Roth, Aug 1, 2003
    #12
  13. Ben S

    Andrew Dalke Guest

    John Roth:
    > Several turns out to be one revision, and I don't think that they
    > got it right either. From what I see, the Python datetime library
    > is actually more complicated than the Java library: it's certainly
    > got more classes, although they seem to be better designed.


    Then I was just spreading rumor.

    I see the following classes in Java:
    java.util.Date
    java.sql.Date
    java.sql.Time
    java.sql.Timestamp
    java.util.Calendar
    java.util.GregorianCalendar
    java.util.Timezone
    java.util.SimpleTimeZone
    java.text.DateFormat
    java.text.SimpleDateFormat

    As for Python ones ...
    datetime.timedelta
    datetime.date
    datetime.datetime
    datetime.tzinfo
    plus the older ones of
    time.*
    calendar (mostly useless, IMHO)

    > For the most part, the applications that need to be aware of leap
    > seconds are the ones that communicate with other servers that
    > are aware of leap seconds, and can report them. As far as I'm
    > aware, leap seconds are a thing of the past anyway: they proved
    > to be more trouble than they were worth to anyone.


    But those tools don't need support for BC-era dates...

    > I'd also expect to see some sort of reasonably well thought out framework
    > where those extensions could simply be plugged in and just work.


    There were some dicussions for that - the idea was that datetime and
    mxDateTime values should be interoperable. I don't recall the details
    of those plans though ... (searching) ... Ahh, a thread starts here
    http://mail.python.org/pipermail/python-dev/2003-January/032100.html
    but I don't know the conclusion.

    > Where was it in March? [grin]. Answer. It depends on where is.


    Sure. Which is why datetime support for then is hard.

    The statement I made in c.l.py years ago was that it's all dependent
    on longitude, lattitude, and additude. Software can handle the first
    two, but not the third, at least not without a lot of work and upkeep.

    > My objection
    > is to exactly one implementation decision: to limit the time range
    > at 1AD. That is, to use the vernacular, a show-stopper. It means
    > that the core of the library has to be reworked if you want to deal
    > with dates before 1AD.


    I gave an idea of a way to work around that, by using an offset
    of 6000 years. I'll look to there for followup.

    > programming. My application date package works for what
    > I need it to do; it just seems that I can't abandon it for the
    > standard Python library package. [Sigh.]


    Does that mean if there was no decision to include datetime in
    Python 2.3 then you wouldn't be able to support your application
    at all in Python? Or would you have just decided to use mxDateTime?
    If the latter, what's preventing you from doing so now?

    Andrew
    Andrew Dalke, Aug 2, 2003
    #13
  14. John Roth fed this fish to the penguins on Friday 01 August 2003 04:16
    am:


    >
    > Frankly, if what was wanted was a single, consistent and usable
    > definition of time, the astronomical Julian date is it. It's a single
    > number,


    Calculated using the J2000 definition, or the B1900 definition?


    --
    > ============================================================== <
    > | Wulfraed Dennis Lee Bieber KD6MOG <
    > | Bestiaria Support Staff <
    > ============================================================== <
    > Bestiaria Home Page: http://www.beastie.dm.net/ <
    > Home Page: http://www.dm.net/~wulfraed/ <
    Dennis Lee Bieber, Aug 3, 2003
    #14
  15. Ben S

    John Roth Guest

    "Dennis Lee Bieber" <> wrote in message
    news:...
    > John Roth fed this fish to the penguins on Friday 01 August 2003 04:16
    > am:
    >
    >
    > >
    > > Frankly, if what was wanted was a single, consistent and usable
    > > definition of time, the astronomical Julian date is it. It's a single
    > > number,

    >
    > Calculated using the J2000 definition, or the B1900 definition?


    AFIK, it hasn't changed. I *think* you're talking about the epoch,
    which is an astronomical thing that's rightly ignored outside of astronomy.
    Even astrologers ignore it: we prefer to know where the vernal equinox
    is at date, not where it is at some other date.

    John Roth
    >
    >
    > --
    > > ============================================================== <
    > > | Wulfraed Dennis Lee Bieber KD6MOG <
    > > | Bestiaria Support Staff <
    > > ============================================================== <
    > > Bestiaria Home Page: http://www.beastie.dm.net/ <
    > > Home Page: http://www.dm.net/~wulfraed/ <

    >
    John Roth, Aug 3, 2003
    #15
  16. John Roth fed this fish to the penguins on Sunday 03 August 2003 03:47
    am:

    >
    > AFIK, it hasn't changed. I *think* you're talking about the epoch,
    > which is an astronomical thing that's rightly ignored outside of


    There is a subtle change in the length of the "year" (besides the
    redefinition of where "0/first point of Aries" is with respect to the
    stars).

    J2000 defines a year as 365.25 days, B1900 used 365.242198781

    From "Spherical Astronomy" (Robin M. Green; 1985 Cambridge University
    Press)

    "... The starting epoch for JD has the same formal definition in every
    time-scale, but will not correspond to the same instant of time. ..."

    While both use 4713BC Jan 1.5 as the "0" point, the moment that point
    occurred differs in the two calculations.

    --
    > ============================================================== <
    > | Wulfraed Dennis Lee Bieber KD6MOG <
    > | Bestiaria Support Staff <
    > ============================================================== <
    > Bestiaria Home Page: http://www.beastie.dm.net/ <
    > Home Page: http://www.dm.net/~wulfraed/ <
    Dennis Lee Bieber, Aug 3, 2003
    #16
  17. Ben S

    John Roth Guest

    "Dennis Lee Bieber" <> wrote in message
    news:...
    > John Roth fed this fish to the penguins on Sunday 03 August 2003 03:47
    > am:
    >
    > >
    > > AFIK, it hasn't changed. I *think* you're talking about the epoch,
    > > which is an astronomical thing that's rightly ignored outside of

    >
    > There is a subtle change in the length of the "year" (besides the
    > redefinition of where "0/first point of Aries" is with respect to the
    > stars).
    >
    > J2000 defines a year as 365.25 days, B1900 used 365.242198781
    >
    > From "Spherical Astronomy" (Robin M. Green; 1985 Cambridge University
    > Press)
    >
    > "... The starting epoch for JD has the same formal definition in every
    > time-scale, but will not correspond to the same instant of time. ..."
    >
    > While both use 4713BC Jan 1.5 as the "0" point, the moment that point
    > occurred differs in the two calculations.


    Undoubtedly true, but it makes absolutely no difference for what
    we're talking about. All we need in this conversation is a mapping
    of days to integers that goes back far enough. Converting from
    GMT / UT / whatever to ET is something that can safely be
    left to the astronomers, and that's what the detail you're talking
    about is concerned with.

    John Roth
    >
    John Roth, Aug 4, 2003
    #17
    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. Ben S
    Replies:
    2
    Views:
    308
    Steven Taschuk
    Aug 1, 2003
  2. Tim Peters

    RE: time, calendar, datetime, etc

    Tim Peters, Aug 2, 2003, in forum: Python
    Replies:
    3
    Views:
    300
    John Roth
    Aug 3, 2003
  3. Tim Peters

    RE: time, calendar, datetime, etc

    Tim Peters, Aug 3, 2003, in forum: Python
    Replies:
    3
    Views:
    363
    John Baxter
    Aug 5, 2003
  4. Christos TZOTZIOY Georgiou
    Replies:
    3
    Views:
    703
    Christos TZOTZIOY Georgiou
    Sep 13, 2003
  5. Tim Peters
    Replies:
    0
    Views:
    529
    Tim Peters
    Sep 9, 2003
Loading...

Share This Page