Date/Time range was Re: [Fwd: [Zope3-dev] Date/Time requirements]

[Gary Poster]

Hi.

From: "Tim Peters" <tim@zope.com>

> This is at worst the leading contender for creative interpretation of
"time
> zone use case" <wink>.

heh.  actually, there was a question somewhere back in this thread if this
were a "general call for date/time type requirements"--to which the answer
was yes.  so, I was trying to be pertinent; sorry if I failed. ;-)  Thanks
for your response anyway.

> Seriously, it sounds like mxDateTime meets your needs as-is.  It caters to
> the Julian calendar already, has no real limitation on year range (+-2**31
> days), and has resolution of 24*3600/2**54 seconds (finer than
nanosecond).

Eh--from http://www.lemburg.com/files/python/mxDateTime.html it looks like
only from 0 CE on is supported, even though I take it from your explanation
that the "Absolute date" C long is practically allowed allowed to be
negative.  I suppose I could bug them about officially sanctioning earlier
dates...or roll my own, which is what I was figuring I would have to do
before I wrote my fevered wiki comment anyway.  If a package does not
officially support earlier dates in any shape or form--even in the
inaccurate sense I suggested on the wiki--then I can't count on them, and
might as well go down my own path that at least I can rely on in the future.

> Our (Guido & friends) prototype code exposes "proleptic Gregorian day
> ordinals" (PGDO) exactly as defined in Dershowitz & Reingold's
"Calendrical
> Calculations", and that's the only concession we intended to make to the
> hundreds of other calender systems out there (Julian included).  You can
> consult the book for canned algorithms to convert PGDO to and from many
> other calendar systems.

that sounds extremely cool, actually...  I wish, then, that you went far
enough back to make it useful for me too, but...

> We're not trying to be all things to all people, because nobody will pay
us
> to work for years on this module.  I confirmed today that Guido doesn't
want
> to bother with negative years in any form, despite that base support for
> them requires only minor fiddling to the prototype code.  The number of
> other things you want is evidence that we'll never hear the end of it if
we
> open that door even a crack.

...understood, of course.  I understood this to be a call for date/time
wishes, and this was mine.  Not all wishes are granted.

That said, I'm a bit confused as to what you mean by the "other things" I
want.  oh--you mean the variable precision?  right, again that was merely a
wish (actually echoing that of others), and some wishes are not granted.
However, if you went back to 5000 BCE and didn't give me the variable
precision then that would be cool enough.  I could do my own subclass for
that kind of thing, and rely on the basic Python date-time you are working
on now for basic functionality...

> You may wish to argue differently against the Python PEP when it's
published
> (Fred Drake is working on it now), or convince Jim Fulton that Zope needs
a
> canned date object extending back so far.

eh.  I'm mostly a shy bird.  I'll go back to my nest and ponder my own
solution when the time comes, or eventually emerge again and pester the
mxDateTime maintainers. :-)

Thanks again for your response, Tim.

Gary