time, calendar, datetime, etc
Kylotan
future? Right now it seems a little awkward to find the function you
want. The main culprit is 'timegm' which is the only thing I need from
the calendar module but which should probably be in the time module.
And does datetime.timetuple() actually return something equivalent to
a struct_time as used by the time module? At first glance this looks
to be true, but it isn't clearly documented as such.
Personally I think 2 separate modules (1 high level, 1 low level
corresponding to the C api) would suffice, or even to combine it all
into one coherent module. Is there any benefit to the status quo that
I am missing?
PS. I use 'time.strptime(myTime, '%a %b %d %H:%M:%S %Y')' as a
reverse-asctime(), and was surprised that I couldn't find this wrapped
in a function in any of the modules. Maybe such a function would be
considered for future addition?
--
Kylotan
Skip Montanaro
kylotan> Is there any chance of these modules becoming somewhat combined
kylotan> in the future?
Maybe. Perhaps you would like to write a PEP?
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?
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?
Skip
Ben S
> 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
> 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?
Sorry...I just rechecked the docs and it would appear that this is the
default behaviour of strptime if you omit the format string. Therefore a
new function isn't needed.
Steven Taschuk
[...]
> And does datetime.timetuple() actually return something equivalent to
> a struct_time as used by the time module? At first glance this looks
> to be true, but it isn't clearly documented as such.
Isn't it?
timetuple()
Return a 9-element tuple of the form returned by time.localtime().
<http://www.python.org/doc/current/lib/datetime-datetime.html>
> Personally I think 2 separate modules (1 high level, 1 low level
> corresponding to the C api) would suffice, or even to combine it all
> into one coherent module. Is there any benefit to the status quo that
> I am missing?
The bulk of the calendar module deals with creating and printing
strings and arrays representing calendar months. Hardly
general-purpose; I wouldn't want to see such things in the
datetime module.
The exception, as you noted, is calendar.timegm(), which, indeed,
the docs describe as "unrelated but handy".
> PS. I use 'time.strptime(myTime, '%a %b %d %H:%M:%S %Y')' as a
> reverse-asctime(), and was surprised that I couldn't find this wrapped
> in a function in any of the modules. Maybe such a function would be
> considered for future addition?
Maybe indeed.
One consideration here is that the time module is, I think,
intended simply as a wrapper over the underlying C API. Afaik
that API doesn't have convenience inverses of gmtime or asctime.
--
Steven Taschuk stas...@telusplanet.net
"Its force is immeasurable. Even Computer cannot determine it."
-- _Space: 1999_ episode "Black Sun"
Juha Autero
> PS. I use 'time.strptime(myTime, '%a %b %d %H:%M:%S %Y')' as a
> reverse-asctime(), and was surprised that I couldn't find this wrapped
> in a function in any of the modules. Maybe such a function would be
> considered for future addition?
That's probably because it's easier to do it with time.strptime(). From
documentation:
The format parameter uses the same directives as those used by
strftime(); it defaults to "%a %b %d %H:%M:%S %Y" which matches
the formatting returned by ctime()
Which means that time.strptime() without format parameter acts as
reverse-asctime().
Maybe documentation should state "which matches the formatting
returned by ctime() and asctime()" since both functions use the same
formatting.
--
Juha Autero
http://www.iki.fi/jautero/
Eschew obscurity!
Ben S
> Quoth Kylotan:
> [...]
>> And does datetime.timetuple() actually return something equivalent to
>> a struct_time as used by the time module? At first glance this looks
>> to be true, but it isn't clearly documented as such.
>
> Isn't it?
>
> timetuple()
> Return a 9-element tuple of the form returned by
> time.localtime().
>
> <http://www.python.org/doc/current/lib/datetime-datetime.html>
Problem is, time.localtime() doesn't return a 9-element tuple any more,
it returns a struct_time. (Since 2.2, I think.)
John Roth
"Ben S" <be...@replytothegroupplease.com> wrote in message
news:bgaphh$lua$1...@news7.svr.pol.co.uk...
Strictly speaking, that's true, but the object that's returned
*acts* like a sequence of 9 integers if you reference it properly.
It seems like 2.2 did this in a number of places, so that you
could reference values by name. I like the thinking behind it.
It's a lot better documentation if you want to get one value at
a time.
John Roth
Skip Montanaro
>> 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
John Roth
"Skip Montanaro" <sk...@pobox.com> wrote in message
news:mailman.1059656902...@python.org...
>
>
> 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
>
>
A.M. Kuchling
Skip Montanaro <sk...@pobox.com> 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.
--amk (www.amk.ca)
Hello! I'm the Doctor. I believe you want to kill me.
-- The Doctor, in "Silver Nemesis"
Skip Montanaro
Ben> Problem is, time.localtime() doesn't return a 9-element tuple any
Ben> more, it returns a struct_time. (Since 2.2, I think.)
Struct_time objects work like tuples, and you get the added
benefit of named attribute access:
>>> t = time.localtime()
>>> t
(2003, 7, 31, 12, 19, 35, 3, 212, 1)
>>> t[2]
31
>>> t.tm_mday
31
>>> t.tm_isdst
1
>>> t[-1]
1
>>> t[0:3]
(2003, 7, 31)
Skip
John Roth
"A.M. Kuchling" <a...@amk.ca> wrote in message
news:1sScnW0Sv7D...@speakeasy.net...
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
Tim Peters
> 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.
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.
> 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.)
The datetime design took place on a Zope Wiki:
http://www.zope.org/Members/fdrake/DateTimeWiki/FrontPage
and Zope Corp funded the work. If more astronomers used Zope, the outcome
may have been different. As things were, fast field extraction for
formatting and fiddling, compact memory representation and pickles,
"practical" dates, fast compaison, and exact arithmetic were goals. See
especially the SuggestedRequirements page in that Wiki. Astronomers were
dissed in its first bullet <wink>.
Steven Taschuk
[...]
> Problem is, time.localtime() doesn't return a 9-element tuple any more,
> it returns a struct_time. (Since 2.2, I think.)
Ah, yes. I read Kylotan's question pretty sloppily, it seems.
datetime.timetuple() does indeed return a struct_time, as do
date.timetuple() and datetime.utctimetuple(), and this is clearly
desirable and intended. I think I'll submit a doc patch.
--
Steven Taschuk o- @
stas...@telusplanet.net 7O )
" (
Christopher Koppler
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!
--Christopher
Andrew Dalke
> 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
da...@dalkescientific.com
M.-A. Lemburg
> 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/
________________________________________________________________________
Ben Finney
> 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/>
John Roth
"Andrew Dalke" <ada...@mindspring.com> wrote in message
news:bgcr5a$8ac$1...@slb9.atl.mindspring.net...
> 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
> da...@dalkescientific.com
>
>
John Roth
"Tim Peters" <tim...@comcast.net> wrote in message
news:mailman.105970626...@python.org...
> [John Roth]
> > 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.
>
> 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.
Oh, agreed.
> > 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.)
>
> The datetime design took place on a Zope Wiki:
>
> http://www.zope.org/Members/fdrake/DateTimeWiki/FrontPage
>
> and Zope Corp funded the work. If more astronomers used Zope, the outcome
> may have been different. As things were, fast field extraction for
> formatting and fiddling, compact memory representation and pickles,
> "practical" dates, fast compaison, and exact arithmetic were goals. See
> especially the SuggestedRequirements page in that Wiki. Astronomers were
> dissed in its first bullet <wink>.
See my response to Andrew Dalke. The basic issue is that the starting
date is too late to be useful. I've got no problem with not including things
like the Julian calendar: not too many people (other than professional
historians working with original documents) realize the incredible mess
around historical dates.
I wouldn't have any problem with wrapping it to get what I want, but
the base date issue is intractible in any significant sense. The remainder
of Andrew's straw men are clearly in extension territory.
John Roth
>
>
John Roth
"Christopher Koppler" <klap...@chello.at> wrote in message
news:f6ojivk3c87s8memo...@4ax.com...
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
Mel Wilson
"Andrew Dalke" <ada...@mindspring.com> wrote:
>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.)
(Also the Royal Navy, in the era of Patrick O'Brians novels.
Apparently because you can determine local noon exactly with
a sun sight, but there's damn all you can do to determine
midnight without a lot of work.)
Regards. Mel.
Andrew Dalke
> 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
da...@dalkescientific.com
Andrew Dalke
> 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
da...@dalkescientific.com
John Roth
> 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.
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
Andrew Dalke
> See my response to Andrew Dalke. The basic issue is that the starting
> date is too late to be useful.
And my reponse is you should have said "... to be useful for you."
It's plenty useful for me and others.
Though if I were to do long baseline interferometry, using a
couple of masers to keep things in synch, then I expect that
datetime would also not be useful for me because I would need
better than microsecond resolution.
When should datetime functionality stop growing to support
smaller and smaller niches?
> I wouldn't have any problem with wrapping it to get what I want, but
> the base date issue is intractible in any significant sense. The remainder
> of Andrew's straw men are clearly in extension territory.
"Intractable?"! What about defining your own class which handles
BC dates, using datetime to do the heavy load? All you need is
your own offset to choose a year which has the same day-of-week
and leapyear behaviour. datetime says 1/1/1 was a Monday, so
you just need a year offset X so that 12/31/X is a Sunday and
where X is a leapyear (or not? Don't know how the leap years
are affected that far in the past.). Looks like X=6000 does the
job.
>>> datetime.date(1970, 8, 22).weekday()
5
>>> datetime.date(6970, 8, 22).weekday()
5
>>>
So what about an offset of 6000 years? Implement your
own class which uses datetime for storage, and just subtract
6000 years from its result to get the real result?
class RothDate(object):
def __init__(self, year, month, day):
self._date = datetime.date(year + 6000, month, day)
year = property(lambda self: self._date.year - 6000)
month = property(lambda self: self._date.month)
day = property(lambda self: self._date.day)
def weekday(self): self._date.weekday
...
d = RothDate(-200, 2, 10)
print d.year, d.month. d.day
print d.weekday()
Doesn't seem that intractable to me, excepting leapyear
behaviours. And is there consensus on that?
Andrew
da...@dalkescientific.com
Andrew Dalke
> 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
da...@dalkescientific.com
Tim Peters
> ...
> 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).
That's what Guido calls "naive time" on the DateTimeWiki (op. cit.). It's
the time he lives in <wink>, and datetime was deliberately designed to
mirror it.
> And then there's timezones and daylight savings time. (And no
> thoughts of "double daylight savings like the British had during
> WWII.")
Time zones are beyond Guido's notion of naivety. There's actually no
support for any particular time zone in 2.3's datetime module, not even UTC
or your local time zone. Instead there's a protocol by means of which
"aware" datetime objects can be taught to play along with user-defined and
user-coded time zone classes. Double daylight in WWII fits easily in this
framework, provided you're motivated enough to bother writing a
double-daylight tzinfo class to model it. I hope the community cares enough
to write a collection of tzinfo classes modeling contemporary time zones,
but if they're waiting for Guido to do it for them, it ain't gonna happen.
sufficient-unto-the-day-are-the-24*3600-seconds-thereof-ly y'rs - tim
Skip Montanaro
Andrew> So again I say, most people don't care that much about the time.
And when they do, it's for at most a few years into the past (taxes, tax
audits) and a few years forward (< 100 years, typically the expected
remainder of their own lifetime). An astromer's view of time is extremely
different and extremely rare. Given that, it's not hard to understand the
epoch year chosen by the people who developed the requirements for the
datetime module.
Maybe Jay Leno should have a "Jay Walking" where he asks people about the
adoption of the Gregorian calendar. That would give you some idea about how
many people care about dates long ago. ;-)
Skip
Tim Peters
> ...
> 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.)
There was a specific reason for picking "year 1": that makes datetime's
date ordinals identical to those used in the base proleptic Gregorian
calendar in Dershowitz and Reingold's highly regarded "Calendrical
Calculations":
http://emr.cs.iit.edu/home/reingold/calendar-book/second-edition/
So people who want umpteen kinds of calendars Guido doesn't care about can
look up algorithms in that book to do conversion to and from datetime's view
of reality. For that reason alone, it was a better choice than most. In
addition, since an explicit goal of datetime was fast extraction of fields,
we simply store the year as given (e.g., 2003 is stored as 2003). This also
works well for fast comparisons. Something missed in this discussion so far
is that commercial applications deal in countless thousands of dates and
datetimes -- formatting, sorting and indexing speed are important to them.
Important enough to Zope Corp to pay the substantial bill for developing
this code, anyway.
i-hear-guido-doesn't-come-cheap-ly y'rs - tim
John Baxter
"Tim Peters" <tim...@comcast.net> wrote:
> [Andrew Dalke]
> > ...
> > 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.)
1904 for Mac, actually. The story is fairly well documented, but...
It was desired to include the entire team's set of birth dates
That didn't get back to 1904, but it got reasonably close to 1900
1900 was rejected because they didn't want to start out in a leap
year exception
They did want to start in a leap year...hence 1904
The 1904 choice has meant that considered as a signed 32-bit number,
Macintosh time has always been negative. "Always" in the sense of when
there were Macintosh machines...the sign change was sometime in 1972, I
think. And since Pascal was the base higher level language, time was
indeed negative. (Macintosh time became signed 64 bits--with 32-bit
clock hardware--around 1991: plenty early to beat the End of Time early
in 2040.)
--John (steadfastly ignoring leap seconds)
Dan Bishop
> "Intractable?"! What about defining your own class which handles
> BC dates, using datetime to do the heavy load? All you need is
> your own offset to choose a year which has the same day-of-week
> and leapyear behaviour. datetime says 1/1/1 was a Monday, so
> you just need a year offset X so that 12/31/X is a Sunday and
> where X is a leapyear (or not? Don't know how the leap years
> are affected that far in the past.).
There were no leap years between 10 BC and AD 4, because after Julius
Caesar's death, the priests in charge of the calendar mistakenly added
leap days every 3 years instead of 4, and this had to be corrected.
I wouldn't expect the datetime module to deal with that, though ;-)
> Looks like X=6000 does the job.
So does any multiple of 400: The Gregorian leap year cycle is 400
years and this is coincidentally also a whole number of weeks.
> >>> datetime.date(1970, 8, 22).weekday()
> 5
> >>> datetime.date(6970, 8, 22).weekday()
> 5
The output above is my least favorite feature of the datetime module.
It took me a while to figure out that those dates are Saturdays.
Perhaps we could add a weekday class to 2.3.1?
DAY_NAMES = ['Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday',
'Saturday', 'Sunday']
class weekday(int):
def __repr__(self):
return DAY_NAMES[self]
for i, name in enumerate(DAY_NAMES):
globals()[name] = weekday(i)
John Roth
"Dennis Lee Bieber" <wlf...@ix.netcom.com> wrote in message
news:ceauv-...@beastie.ix.netcom.com...
> 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,
>
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
>
>
> --
> > ============================================================== <
> > wlf...@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
> > wulf...@dm.net | Bestiaria Support Staff <
> > ============================================================== <
> > Bestiaria Home Page: http://www.beastie.dm.net/ <
> > Home Page: http://www.dm.net/~wulfraed/ <
>
John Roth
> Tim Peters fed this fish to the penguins on Friday 01 August 2003 07:30
> pm:
>
> > Gregorian calendar in Dershowitz and Reingold's highly regarded
> > "Calendrical Calculations":
> >
> > http://emr.cs.iit.edu/home/reingold/calendar-book/second-edition/
> >
> > So people who want umpteen kinds of calendars Guido doesn't care about
> > can look up algorithms in that book to do conversion to and from
> > datetime's view
>
> BASIC would be more accessible to most folks <G> (though I would prefer
> a modern BASIC over G-whiz or older).
That's the version I have (somewhere.) As I've said a couple of times,
it's not the lack of built-in support for all kinds of strange calendars
that's
the problem: it's the decision to limit the time span to 1AD.
Tim Peters
> There were no leap years between 10 BC and AD 4, because after Julius
> Caesar's death, the priests in charge of the calendar mistakenly added
> leap days every 3 years instead of 4, and this had to be corrected.
>
> I wouldn't expect the datetime module to deal with that, though ;-)
Thank you -- some people did <wink>.
> ...
> >>> datetime.date(1970, 8, 22).weekday()
> 5
> >>> datetime.date(6970, 8, 22).weekday()
> 5
>
> The output above is my least favorite feature of the datetime module.
> It took me a while to figure out that those dates are Saturdays.
That's very peculiar! Because they're not both Saturdays:
>>> datetime.date(1970, 8, 22).weekday()
5
>>> datetime.date(6970, 8, 22).weekday()
2
>>>
Or if you want names instead:
>>> datetime.date(1970, 8, 22).ctime()[:3]
'Sat'
>>> datetime.date(6970, 8, 22).ctime()[:3]
'Wed'
>>>
Did you actually run the example you pasted, or just assume that the second
line would display 5 too, or didn't paste the actual example you ran and
made a typo?
The earlier claim:
> The Gregorian leap year cycle is 400 years and this is coincidentally
> also a whole number of weeks.
was correct, but the 5000 years between 1970 and 6970 isn't a multiple of
400, so the example as given wasn't relevant to that claim.
> Perhaps we could add a weekday class to 2.3.1?
>
> DAY_NAMES = ['Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday',
> 'Saturday', 'Sunday']
> class weekday(int):
> def __repr__(self):
> return DAY_NAMES[self]
> for i, name in enumerate(DAY_NAMES):
> globals()[name] = weekday(i)
I doubt anything like this will get added, in part because we have the
unfortunate fact that .weekday() and .isoweekday() map day names into little
integers differently. As shown above, you can easily get English day names
(well, abbreviations) from the .ctime() result. A .strftime() format works
too, except .strftime() has irritating year-range limitations inherited from
C.
I have a little dateutil.py module I use for my own stuff, containing
MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY = range(7)
(JANUARY, FEBRUARY, MARCH, APRIL, MAY, JUNE,
JULY, AUGUST, SEPTEMBER, OCTOBER, NOVEMBER, DECEMBER) = range(1, 13)
at the start. That's easy, and caters to that (1) I'm unlikely ever to use
.isoweekday(); and, (2) after decades of practice, I'm comfortable with the
English names for these things. It's much easier to do something similar
for yourself than to try to define a gimmick that covers the union of all
peoples' crazy ideas <wink>.
Tim Peters
deliberately defined to be identical to those used in
> Dershowitz and Reingold's highly regarded "Calendrical Calculations":
>
> http://emr.cs.iit.edu/home/reingold/calendar-book/second-edition/
]
[Dennis Lee Bieber]
> Pity the book uses LISP (at least, the first edition did)...
> Even BASIC would be more accessible to most folks <G> (though I would
> prefer a modern BASIC over G-whiz or older).
I'd prefer Python, myself. It would be a fun (for a date weenie <wink>)
project to recode these algorithms Pythonically. I hope someone does.
Andrew Dalke
> Did you actually run the example you pasted, or just assume that the
second
> line would display 5 too, or didn't paste the actual example you ran and
> made a typo?
Typo. I do usenet through MS Windows and haven't upgraded yet.
It's my OS X box's Python which has datetime support. When
copying I thought to myself "add 6000 years" which got turn into
"replace the thousand year position with a 6". Guess it's time to
break out the sackcloth and ashes. :)
Any suggestions for a decent usenet reader for OS X?
Andrew
da...@dalkescientific.com
Aahz
Pick any standard Unix reader: trn3.6, trn4, slrn, tin, pine, gnus, ...
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
This is Python. We don't care much about theory, except where it intersects
with useful practice. --Aahz
Andrew Dalke
> Pick any standard Unix reader: trn3.6, trn4, slrn, tin, pine, gnus, ...
I *like* GUI-based email and usenet programs.
(And unlike you, I find lynx to be a confusing browser. Eg,
when there are two links, side-by-side, I keep pressing
the right arrow key to go from the left to the right, which
lynx hears as "descend into the current link.")
Andrew
da...@dalkescientific.com
John Roth
> 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
>
> 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
> [Dan Bishop]
> > There were no leap years between 10 BC and AD 4, because after Julius
> > Caesar's death, the priests in charge of the calendar mistakenly added
> > leap days every 3 years instead of 4, and this had to be corrected.
> >
> > I wouldn't expect the datetime module to deal with that, though ;-)
>
> Thank you -- some people did <wink>.
I don't think I noticed that: the entire point behind the proleptic
calender is that you're projecting the current practice back to
times where they weren't doing it that way.
That's clearly an opportunity for someone to add an extension -
except that there are other problems in that era, and the lack
of leap years is the least of them.
John Roth
John Roth
Well, where's the hook in the module for someone to add additonal
calendar classes?
John Roth
>
>
Tim Peters
>>> There were no leap years between 10 BC and AD 4, because after
>>> Julius Caesar's death, the priests in charge of the calendar
>>> mistakenly added leap days every 3 years instead of 4, and this had
>>> to be corrected.
>>>
>>> I wouldn't expect the datetime module to deal with that, though ;-)
[Tim]
>> Thank you -- some people did <wink>.
[John Roth]
> I don't think I noticed that:
Were you a participant in datetime's design process (the fishbowl on
zope.org, previously referenced)? If so, sorry, I don't recall it.
> the entire point behind the proleptic calender is that you're
> projecting the current practice back to times where they weren't
> doing it that way.
And forward too, of course. But not everyone *wanted* a proleptic calendar
(of any flavor). The use cases on the datetime wiki turned out not to care
either way (business uses generally don't give a rip about years before
1900), so I pushed for the conceptual simplicity of the proleptic Gregorian
(which coincides with current reckoning in much of the world, so satisfied
the use cases).
> That's clearly an opportunity for someone to add an extension -
> except that there are other problems in that era, and the lack
> of leap years is the least of them.
People who care can scratch their own itches.
John Roth
> [Dan Bishop]
> >>> There were no leap years between 10 BC and AD 4, because after
> >>> Julius Caesar's death, the priests in charge of the calendar
> >>> mistakenly added leap days every 3 years instead of 4, and this had
> >>> to be corrected.
> >>>
> >>> I wouldn't expect the datetime module to deal with that, though ;-)
>
> [Tim]
> >> Thank you -- some people did <wink>.
>
> [John Roth]
> > I don't think I noticed that:
>
> Were you a participant in datetime's design process (the fishbowl on
> zope.org, previously referenced)? If so, sorry, I don't recall it.
No. I didn't even know about it until recently.
> > the entire point behind the proleptic calender is that you're
> > projecting the current practice back to times where they weren't
> > doing it that way.
>
> And forward too, of course. But not everyone *wanted* a proleptic
calendar
> (of any flavor). The use cases on the datetime wiki turned out not to
care
> either way (business uses generally don't give a rip about years before
> 1900), so I pushed for the conceptual simplicity of the proleptic
Gregorian
> (which coincides with current reckoning in much of the world, so satisfied
> the use cases).
And I agree with that reasoning. There's no way that the module
core can deal with historical and other cultural dates in any consistent
or comprehensive fashion, so it shouldn't waste effort and try. On the
same token, though, it shouldn't get in the way of people who want to
extend it to handle additional calendar types, or bring dates back before
1AD.
> > That's clearly an opportunity for someone to add an extension -
> > except that there are other problems in that era, and the lack
> > of leap years is the least of them.
>
> People who care can scratch their own itches.
Exactly.
John Roth
>
>
Andrew Dalke
> Well, where's the hook in the module for someone to add additonal
> calendar classes?
Why does the module need a hook? Write a new module, possibly
deriving from existing classes or interfaces.
Andrew
da...@dalkescientific.com
Andrew Dalke
> On the
> same token, though, it shouldn't get in the way of people who want to
> extend it to handle additional calendar types, or bring dates back before
> 1AD.
But it doesn't. I showed an easy way to derive from the datetime
class to support dates before 1AD, by doing an offset of 6,000 years.
class RothDate(object):
def __init__(self, year, month, day):
self._date = datetime.date(year + 6000, month, day)
year = property(lambda self: self._date.year - 6000)
month = property(lambda self: self._date.month)
day = property(lambda self: self._date.day)
def weekday(self): self._date.weekday
...
d = RothDate(-200, 2, 10)
print d.year, d.month. d.day
print d.weekday()
Andrew
da...@dalkescientific.com
John Baxter
"Tim Peters" <tim...@comcast.net> wrote:
> [Dan Bishop]
> > There were no leap years between 10 BC and AD 4, because after Julius
> > Caesar's death, the priests in charge of the calendar mistakenly added
> > leap days every 3 years instead of 4, and this had to be corrected.
> >
> > I wouldn't expect the datetime module to deal with that, though ;-)
>
> Thank you -- some people did <wink>.
One interesting bit of reading about this stuff comes from the nice
folks at
http://www.wundermoosen.com
(in fact, I see they've put out some more calendar white papers,
including "How we figured out the Viking calendar.")
Look under Calendar X for the Viking calendar paper, "The Mayan
Calendar" and some others.
The paper I was thinking of when I started this is around here
somewhere, but I don't immediately see it on the site. It was referred
to by (shipped with?) Calendar2000. It includes a good view of when
various countries switched from Julian to Gregorian (and in at least one
case switched back and switched again).
--John