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

[Tim Peters]

[Gary Poster]
> More time zone use cases/thoughts:
>
>  - Even though Julian, Hebrew, etc. calendars are not supported,
> it would be extremely useful if the official Python class decided on a
> solution to the B.C.E. (B.C.) problem, and if it could *approximately*
> handle  dates getting closer to the beginning of recorded human history.
> Perhaps around 4236 B.C.E. (earliest date on Egyptian calendar)?  This
> would also include the Hebrew calendar (3760 B.C.E.).  5000 B.C.E. is a
> nice round number, for instance.
> ...

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

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).

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.

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.

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.