[Zope3-dev] tzinfo

[Patrick K. O'Brien]

I wanted to ask a few questions and raise a few issues related to tzinfo.
These are mostly off the top of my head, and aren't meant as definitive
arguments. I just want to get my thoughts out in the open.

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

The current design suggests a naive datetime class plus a subclass that
provides a hook for others to extend the meaning of (and alter the
calculations applied to) a naive datetime (which I will now simply refer to
as a datetime). There seems to be something of a concensus that this basic
approach is a good one.

The issues that we wish to delegate to this subclass have to do with
timezone (however that is defined) and Daylight Saving Time (DST). There is
a fair amount of ambiguity concerning the meaning of these terms. Because we
are delegating responsibility for resolving this ambiguity to a hook, I
think we want to avoid implying more than we should with regard to this hook
and the requirements we place on this hook.

For example, the hook is currently defined as a tzinfo instance. The name
implies that the instance is for informational purposes dealing with
timezone. But one of its functions is dealing with DST, which some people
feel is a separate concern from timezone. And a tzinfo subclass may do more
than just supply information. So I'm wondering if this is the most
appropriate name. Likewise, is datetimetz the most appropriate name?
Especially since a datetimetz with a tzinfo of None is the same as a
datetime.

So, for now, I'm going to refer to datetimetz as datetimex (as in extended,
not the watch manufacturer) and tzinfo as dtx (as in datetime extension).
Not that these are good names, simply that they are sufficiently ambiguous.

Then we get to the names of the hook methods, which datetimex and dtx share:

tzoffset() returns the offset east of UTC, in minutes. Could we avoid
arguments about the meaning of timezone if we simply called this toffset
instead? A toffset returns an offset to a time expressed in minutes east of
UTC, for whatever reason a dtx chooses. (Except that a separate method
exists to deal with DST. But a dtx subclass writer could choose to bundle
the two notions together in this method if they really wanted to, I
suppose.)

tzname() returns a string that names the intended timezone. What about the
fact that a dtx may have multiple names for its notion of an individual
timezone? Should this return a tuple, instead of a string? Should it be
tznames instead of tzname?

tzisdst() returns 0 if DST is not in effect, or the DST offset if DST is in
effect. This sounds like a simple truth function, but it returns an offset.
Should it be named dstoffset instead? Then we would have toffset and
dstoffset, which seems to be nicely symmetrical.

tzinfo() returns the tzinfo object. This would be renamed to match the hook,
such as dtx().

---
Patrick K. O'Brien
Orbtech