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

[Guido van Rossum]

I know that most of this discussion is irrelevant now that I've
expressed enthusiasm about tzinfo objects, but I want to gripe a
little bit.

> I've read the wiki pages and much of the discussion on python-dev,
> and I'm actually not sure what the real issues are with timezone
> support. I've seen the incredibly complex examples concerning adding
> datetimes from different timezones across DST boundaries and
> such.

The example in this page:

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

is far from complex.  It only involves one time in one timezone, and
asks the question what should happen if we add a whole number of days
across a DST jump.  Re-read the page before you reply, please.

> And I'm sure those are a real pain. What I haven't seen is how
> far one can go with a timezone aware datetime before you run into
> problems.
> 
> For example, let's assume we have a datetime with timezone but
> without any notion of leap seconds or DST. Now, it seems to me that
> this datetime can support just about any calculation with a delta
> value because the timezone remains fixed. Right? If I add or
> subtract a certain number of days or hours or seconds, I don't
> expect the timezone to change. I expect it to remain constant. So
> that shouldn't be a problem.

The problem explained with great care in the NaiveTime page mentioned
above is that when "timezone" corresponds to local time before the
addition, it may or may not correspond to local time after addition.
That's the DST problem in a nutshell.

> Then we get into issues like adding and subtracting months and how
> to deal with the fact that months aren't all of a common length. But
> this issue is completely separate from whether or not timezones are
> involved. (Again, ignoring DST issues.)

Agreed, and it's not part of the reason to want to ignore timezones --
so don't bring it in, please.

> Next, I want to be able to represent a datetime in some other
> timezone.  Again, this doesn't seem all that difficult and I believe
> the prototype already supports this.

It did until I ripped it out. :-)  See the CVS history linked to from
the Wiki.

> And while it would be easy enough for a subclass to do the
> conversions, somehow it seems like life will be much more difficult
> if the underlying datetime didn't have the bits to store the
> timezone.

A subclass can add bits, remember?

> That leaves us with calculations involving two datetime values. For
> this, it seems like we could convert the two values to a common
> timezone and perform the calculation. The result should be the same
> as calculations between two datetimes that had no knowledge of
> timezone (naive datetime).

So are April 6 and 7, US/Eastern, in the same timezone or not?  They
have a different tz offset, because one is standard time and the other
is DST.  (Fortunately the tzinfo object proposal addresses this --
there can be a tzinfo object representing "US/Eastern", with the DST
rules built-in.)

> What about applications that don't care about the timezone? It would
> be nice if some notion of "no zone" or "unspecified zone" or "local
> zone" were supported. This could even be the default for cases where
> a timezone wasn't specified. In a way, this would be similar to
> "naive datetime". The difference is that a specific timezone could
> be assigned later,

Since datetime objects are immutable (this is an absolute requirement
in the specs, coming from the Zope Pope), assigning a timezone has to
be done by creating a new object anyway.  It might as well be a
subclass instance then.

> or the timezone could default to the local timezone.  But this is
> different from "naive datetime" in that datetime would still be
> timezone aware, even if a specific instance lacked a specified
> timezone value.

Indeed.

> So, what am I overlooking? Is there a list of "attendant surprises"
> somewhere? Where do my arguments come up short? Or does some of this
> (I hope) make sense? Is there any hope for timezones in datetime?

Yes.

--Guido van Rossum (home page: http://www.python.org/~guido/)