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

[Patrick K. O'Brien]

Guido van Rossum wrote:

[snip]
>
> 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/nondi
> st/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.)

Okay. I've read the NaiveTime page. It seems to me that the real problem is
Daylight Savings Time (DST) and not necessarily timezone. Would you agree?
If there were no such thing as DST, would you still feel that timezone
"makes decent time arithmetic impossible"? If not, and it really is DST that
is throwing a wrench in the works, would it make sense to have the base
datetime object deal with timezones in a DST ignorant way, and leave it up
to a subclass to add the DST handling, rather than dropping timezones
altogether?

arguing-for-timezone-in-datetime-with-my-every-breathly-yrs,

---
Patrick K. O'Brien
Orbtech