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

[Tim Peters]

[Jim Fulton]
> I think time zones are an important requirement of a date-time
> type. Tim Peters has rightfully asked for time-zone use cases. If
> you have time-zome use cases, they'd be helpful.

[Guido van Rossum]
> Let me emphasize that.  Unless there are some use cases and
> requirements in the Wiki, the new datetime class won't have any
> timezone support.  Here's the Wiki:
>
> http://www.zope.org/Members/fdrake/DateTimeWiki/FrontPage

Let me emphasize that more <wink>.  This is also mixed in with "daylight
savings time" (DST).

Are TZs alone sufficient?  Is DST needed?  When shipping a datetime across
the web, is it enough to have one combined TZ+DST offset from UTC?  Or do
you need to get at the TZ *name* as the original datetime creator thought of
it?  Ditto their view of whether or not DST was in effect?  (Note that from
a TZ offset alone, or a combined TZ+DST offset alone, it's impossible to
guess.)  Do exact DST and TZ rules need to be followed by the intersection
of geographic location with time, including historical quirks?  Or is a
"proleptic" (virtual -- artificially uniform) approach good enough (assuming
TZ and/or DST are needed at all)?  If not, how can that be implemented,
given that different OSes don't agree on the rules to use either, and some
web languages (like Javascript) specifically *require* that historical truth
be ignored?  If you add "24 hours" to a datetime object the day before a DST
switch, do want to get back a datetime object with "the same time, next
day", or do you want to act as if exactly 24 hours elapsed and so get back
"the next day, with a time plus or minus an hour off from today's"?  Does
your answer change if you add "1 day" instead of "24 hours"?  What about
"24*3600 seconds"?  Why -- are you nuts <wink>?

That's the tip of the zoneburg.  Guido's idea of a "naive time" base class
ignores all of that, and *I* think is essential to sanity for people who
just don't care to deal with this mess and its attendant surprises.  That
doesn't mean we wouldn't be happy to supply TZ/DST support in a subclass,
and note that Python 2.2 makes it possible to do efficient subclassing at
the C level.