[Zope3-dev] Can we remove ZopeLegacy for now?

[Guido van Rossum]

> Is this a general call for date/time type requirements?  :) Ty and I
> have a pure-Python date/time library we use that supports
> recognition and parsing of a wide variety of human-readable
> date/time formats, and supports time zones and Unix times well
> (e.g. you can convert between timezones by changing the zone
> attribute of a date/time object).  We're happy to contribute code,
> if it helps cut down on the number of date/time libraries that we
> have to convert between, when using Zope and other Python tools.

> Of course, if we can implement our extra features by subclassing the new 
> standard type, that's probably quite acceptable.  :)

I consider *parsing* any form of date/time not a requirement for the
datetime work I'm doing for Python, but it would be great if your
library could build on the Python datetime class.

Please have a look at the prototype; there's a Wiki:

    http://www.zope.org/Members/fdrake/DateTimeWiki/FrontPage

and a prototype implementation in a corner of the nondist Python CVS
tree:

    http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/nondist/sandbox/datetime/

I expect that something like this will be a standard library module in
Python 2.3.  Now is the time to give feedback.  Note that the latest
design ideas are in the "NaiveTime" part of the Wiki -- this means
dropping the timezone from the datetime representation, because it
makes decent time arithmetic (e.g. adding whole N days to a datetime)
impossible.  But it's easy to add the timezone info in a subclass --
if you promise not to do time arithmetic or not to care how it
interoperates with DST transitions.  (Read the NaiveTime page before
commenting on this statement.)

--Guido van Rossum (home page: http://www.python.org/~guido/)