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

[Tim Peters]

[Phillip J. Eby]
> 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.

Used how?  This needs a defined interface.  Note that "Unix ticks value" is
ill-defined across several dimensions:  whether or not it reflects leap
seconds, its resolution (sub-second or not, and if so how fine?), and date
range (the most recent POSIX/Single Unix Specification revision *still*
doesn't require time_t to "work" after 2038).  The Wiki requirements so far
have spelled out "no leap seconds, at least millisecond resolution, and
works for at least 1800-3000".  Guido's latest specific proposal answers
those "no leap seconds, microsecond resolution, (proleptic Gregorian) years
1-9999".

> The default "zone object" would be either a "localtime" zone object
> which effectively makes date/time objects behave as currently spelled
> out,

Which date/time objects do you have in mind here?  Zope's DateTime.py?
Guido's version of "naive time" doesn't know about DST, so is a dicey
candidate for "localtime" from some peoples' views.

> or a "utctime" zone object which treats  the date as UTC.  Any other
> policies can be implemented as a seperate zone object.

So this is pure mechanism, and no policy (i.e., it doesn't actually answer
any of the questions I asked, it's a means by which somebody else could
answer them).  Not meant to be pejorative, just clarifying.

> Note that a zone object is *not* an offset, it is essentially a
> Strategy object.

How many layers of abstraction can people deal with?  Seriously.
Programmers believe <wink> they know what UTC offsets mean -- how many
layers of stuff do they have to navigate before they can use "a Strategy
object" in a way they feel confident about?  (I don't know -- I'm asking
people -- so far it's too vague for me to answer for myself.)

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

Right.  Does anyone ever answer the questions <wink>?

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

I view a zone object as an implementation approach.  In the absence of
concrete use cases, I find it impossible to judge the relative merits of
implementation approaches.  Perhaps something much simpler and hard-coded
would suffice; perhaps zone objects aren't general enough.

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

I can't tell without use cases.  We invited people to specify use cases on
the Wiki, via submitting specific tests:

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

That idea didn't work.  We did get someone list a requirement:

    + Arbitrary time zone daylight saving time is out of scope.

I don't even know what that means.  These concepts are so overloaded I
really need to see I/O examples of exactly how people want things to work in
the end, when they're writing an app and can no longer put off answering the
questions.  If the only thing Zope coders actually need is US Eastern time,
cool <wink>.

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

I believe Guido's idea of "naive" is naiver than yours.

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

Is it the case that many Zope coders will want to roll their own answers?  I
guess I'd be surprised -- most people who aren't experts in a given field
usually just want a specific set of answers worked out for them, and a set
they can rely on in all contexts.  Once "the answer" is "supply a zone
object", then there's more than one of those, and then the inevitable layers
of defaults, and overrides, and adapters to allow your favorite zone objects
to coexist with somebody else's, will follow.  Is the generality worth the
costs?  If a zone object is the Unicode of time gimmicks, not all experience
with Unicode is a joy ...

Or is UTC the Unicode of time gimmicks, and there's an implicit assumption
that all zone objects *can* convert to and from some specific, fixed flavor
of UTC?  If the latter, is that mapping a bijection, or can it be
many-to-one in one direction?  For example, if an astronomer needs
nanosecond resolution (and they do), the canonical UTC form has to be at
least that fine-grained else astrotime -> UTC is an information-losing
conversion.

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

That isn't apparent from what you've said.  I've read that zone objects can
implement any policies whatsoever, so I don't see how you could mix them
without deep knowledge of the policies they implement -- or, IOW, an N**2
explosion of zone object adapters.  Unless there's an implicit appeal being
made here to a "universal UTC" kind of thing.

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

I doubt that an app with its own notion of time will trust a calendar
display routine with some other notion of time.  The app will more likely
want to display datetimes in ways that faithfully reflect its own view of
how dates and times work.  If you want them to work together *without
surprises*, I'm afraid they're going to have to agree on how they view dates
and times from the start (a common set of answers that can be relied on
across components), or one is going to need deep knowledge about the other's
views (a potentially N**2 matrix), or the set of *possible* views zone
objects can model have to be limited in pre-agreed ways (to reduce N**2 to a
finite collection of predefinable parameterized conversions -- "I'm zone
object Z231A, and I answer (7, 52, 1) to question 1, (4, 100, 400) to
question 2, and 0x5FE302D to question 3, and that defines everything
interesting about me").

Or maybe not <wink>.  Without concrete use cases, it's a trackless void.