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

[Phillip J. Eby]

At 07:40 PM 3/12/02 -0500, Tim Peters wrote:
>[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)?

My take on this would be to use an (optional) "zone" field which points to 
a "zone object" that is used to address these policy issues, by permitting 
conversion to/from a Unix ticks value.  The default "zone object" would be 
either a "localtime" zone object which effectively makes date/time objects 
behave as currently spelled out, or a "utctime" zone object which treats 
the date as UTC.  Any other policies can be implemented as a seperate zone 
object.  Note that a zone object is *not* an offset, it is essentially a 
Strategy object.


>   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>?

The answer to all the above is, "it depends on the policy implemented by 
the zone object".



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

Should I take that to mean your vote is that I not prepare a formal 
proposal and use cases for flexible zone support to target for 2.3, but 
instead address these as a subclass?  That's fine with me, I'd just rather 
not waste effort on the proposal if the PythonLabs folks would prefer not 
to put a zone hook in the base class.  IMHO, having an interface for zone 
objects (or "calendars", if you prefer) defined for the first release would 
be really nice, even if the default implementation uses a "naive" zone 
policy like "localtime" or "utc".

To put in another way, I'd like to see a zone hook in 2.3; I can then 
easily make zone policy classes that will implement the behavior that *I'd* 
like to see, without having to subclass the datetime type.  I'm concerned 
that rampant subclassing will create an MxN combinatorial explosion of 
datetime conversion routines.  A zone hook would allow me to take any 
"foreign" datetime object and convert it to one that supports my zone 
policies, in a uniform way.  Datetimes could then be freely exchanged 
between say a database API, an application framework, and a calendar 
display routine, each using different calendars or timezone policies, if 
desired.