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

Gary Poster Gary Poster" <garyposter@earthlink.net
Wed, 13 Mar 2002 11:29:22 -0500


Perhaps this is a variant of the great evil, cross-posting, but I just put
this on the wiki
(http://www.zope.org/Members/fdrake/DateTimeWiki/SuggestedRequirements
comment #3) and wanted to introduce it here as well in case it sparked any
more discussion on this thread.

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.

   For my purposes, it would be acceptable to have a "rolling guarantee" of
sorts: hypothetically, comparison and transformation operations by the
implementation are required to be accurate by seconds 1800-4999 C.E. (A.D.),
by minutes 1582-1800 (1582 is introduction of Gregorian calendar), by day 0
to 1582, and by year 5000 B.C.E. to 0 C.E.  It would still operate as if the
Gregorian calendar were in effect 5000 B.C.E. to 1582 C.E., of course.  Or
whatever you thought was feasible.  Importantly, one could use finer-grained
operations than the "guaranteed" ones without errors: only the docs would
clarify the accuracy limitations.

   The problem domains for this focus on the historical, of course: it would
be *extremely* useful for the fields of literature, music, librarianship,
theology, general history, and other fields if there were "one date/time to
rule them all".  Having an arbitrary cut-off date of 1800 or 0 C.E. is
frustrating; the cut-off date does have to be decided upon, of course, but
why not use a start date that is in fact tied with (one of the?) oldest
known calendar systems?  Otherwise cataloging and historical systems are
invariably required to roll their own.  A cut-off of 5000 B.C.E. would not
include cave art (20000 BCE) but would include most other human-centric
problem domains.

 - Tied in with this, as has been "discussed
elsewhere":http://mail.python.org/pipermail/python-dev/2002-February/020474.
html , is the ability to set a date/time with varying degrees of
specificity/precision, e.g. a date object set to 1800 C.E. would be able to
report back that month, day, hour, minute, millisecond are undefined.
Perhaps, again as has been discussed elsewhere, this would be a subclass,
but an official one would be ideal.