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

[Patrick K. O'Brien]

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

No problem. I'm sure I deserve it. ;-)

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

Fair enough. In my sweeping statement I was referring to more than just your
one example. But still, I exaggerated and misspoke. I really should have
said that I had difficulty understanding all the examples, rather than
accuse the examples of being complex. Mea culpa.

[snip]

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

And that seemed flawed to me. But that was because of my personal
interpretation of the meaning of timezone and local time, which I'll explain
below.

[snip]

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

Yes. ;-) What I was really trying to argue for was a Python Standard Library
version that had some notion of timezone and gave everyone a common starting
point. Which is exactly what you've proposed with tzinfo.

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

Okay. This is where I realized that I've been coming at this problem with a
certain assumption about timezones that may not be shared by everyone (and
is probably due to my own ignorance, but what the heck). I was seeing April
6 and 7, US/Eastern as being in the same timezone. Yes. Here is why.

When I think about what time it is here at my computer, and what time it is
over there at your computer, I ask myself the following questions. Where is
Guido physically located in the world? And what timezone (assuming there is
only one timezone for each place in the world) is associated with Guido's
part of the world? And is Daylight Savings Time in effect right now in
Guido's part of the world? (Thinking of places like Arizona that do not
follow DST.)

Now this may be wrong, or naive. But this is how I think about the issue. I
see a timezone as defining a particular physical region of the world. I see
a one-to-one correspondence between each region of the world and each
timezone. I then see DST as an offset that is applied or not, depending on
the time of the year, and/or depending on a physical subset of that
particular region (Arizona, for example).

Therefore, I assume that any calculations involving a date and some delta
would result in a new date in the exact same timezone. Because moving
forward or backward in time is different than moving forward or backward (or
left or right) in space. To change timezones (to me) implies changing
location. Like flying from where I am now to some other country. If I
physically move, I could very well change timezones. If I merely move from
this day to the next, I remain in the same timezone. And if I happen to move
into the day when DST goes into effect, I change my clock.

Now this may not be how timezones are encoded today. But I would argue that
this might be a mistake. I think the issues of location, timeline, and DST
should be kept separate. They are not the same thing and to mix them all
together creates problems. To me, this is like classic database design. Each
field in a database is supposed to hold an atomic unit of data. That's why
the database designer in me keeps wanting to split these apart and deal with
each separately.

[snip]

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

Good. I hope this message helps as well. Like I said before, I'm doing my
best to get up to speed on the issues. Thanks for being patient. :-)

---
Patrick K. O'Brien
Orbtech