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

[Guido van Rossum]

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

This is the most useful view.  The trick is how to implement it;
nothing simpler than an arbitrary complex tzinfo object supports this
view.  Certainly a simple tzoffset (as the first datetime design has;
see the wiki) doesn't cut it, and neither does a tzoffset plus a DST
bit.

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

(BTW, it's Daylight Saving Time, not SavingS. :-)

I'm not sure why you distinguish DST from the timezone.  A timezone,
in its full generality, is a function from UTC to tzoffset values,
mapping each UTC timepoint to a tzoffset that determines what to add
to UTC to get local time.  Most timezones are step functions, mapping
to two different tzoffset values that are usually an hour apart, and
mapping to one value during approximately one half of the year, and to
the other during the other half.  But there could be other functions.

(An amusing one that I've once heard described as an invention of an
uncle of a landlord of mine has a sawtooth shape: the tzoffset
gradually increases for half a year, and then gradually decreases It
means you never have to move your clock by an hour; rather, you lose
or gain approximately 20 seconds per day, which at the time that this
was proposed (over half a century ago) was within the accuracy of the
watches and clocks that most people used.)

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

So far I agree 100%.

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

That's a way to describe the step function I mentioned, yes.  if you
follow the URL I gave before
(http://webexhibits.org/daylightsaving/g.html) you'll see that most
timezones are described by

(1) a base tzoffset;

(2) an alternative tzoffset;

(3) a rule to decide on what day the switch falls (e.g. "first Sunday
    in April");

(4) a rule to decide at what time the clock is moved (e.g. in the US,
    the clocks move at 2am local time; in the EU, they move at 1am UTC
    regardless of time zone).

Unfortunately, the rules for (3) and (4) have historically varied, and
so have the numbers used for (1) and (2).  The only general solution
uses a table lookup based on jurisdiction (which is more general than
location!) for past years and an arbitrary algorithm for future years.
Also note that according to the above URL, Israel decides the dates
every year, and in general for dates far in the future there's no
telling what the rules will be in a given jurisdiction (and whose
jurisdiction applies in a given location :-).

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

Yup.  Exactly right.

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

I agree that a mere tzoffset is insufficient.  I claim that a tzoffset
and a DST offset are still insufficient -- if you want to support
date/time calculations *and* want to be able to always calculate the
UTC offset for a given date/time in a given timezone, you have to have
the entire UTC-to-tzoffset function available.

Fortunately, tzinfo objects support this.  I've added this to the Wiki
now:

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

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

I enjoy exploring the issues myself. :-)

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