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

[Guido van Rossum]

[Tim]
> > Guido doesn't like this, but I expect your basic intuition is correct:  DST
> > is not part of timezone, and indeed we already got ourselves into trouble
> > by mixing the two into a single tzoffset field (that's basically why *all*
> > the tz code got thrown out of the prototype:  it wasn't clear what the heck
> > it was doing across DST switches,

[Wade]
> I think there are two senses in which 'timezone' and 'DST' are used.

Sure.  See my response to Patrick a moment ago.

> 1. Simple. A timezone is an offset from GMT. A timezone that switches to DST 
> in the spring changes its identifier, e.g. from EST to EDT.
> 
> 2. Complicated. A timezone is a part of the world where everybody agrees to 
> set their clocks the same way. So in the eastern United States, in the 
> wintertime your time zone (sense 1) is EST, and in the summer it's (sense 1) 
> EDT. Unless you are in Indiana, where they stay on EST year-round. (The 
> Windows control panel gives you a separate selection for Indiana when you go 
> to set the date and time.)
> 
> In the shared-calendar use case, data supplied by the clients can
> always have sense 1. (Right now in Ithaca NY it is 19:23 EST.) It's
> when you go to schedule a meeting for this coming summer that you
> get into trouble. 2400 hours from now it will be 20:23 EDT on June
> 23. In Indiana they will call it 19:23 EST.
> 
> It seems to me that it is reasonable for a datetime class to support
> sense 1.  Sense 2 is the application's responsibility: Fred is in
> Indiana, so on his calendar the Fourth of July conference call is at
> 10 o'clock EST, while for the people in NYC it starts at 11 EDT. The
> application has to know whether or not a client observes daylight
> savings time. And if different zones spring forward & fall back on
> different dates, the application has to know that too.
> 
> For sense 1, I don't think you want a DST property that's different
> from your timezone property. EDT and EST are different
> timezones. EDT is represented in the datetime object as (-4, 'EDT')
> and EST as (-5, 'EST').

Sense 1 is incompatible with date/time computations.  If all you have
is an offset, it is not safe to assume that 6 months later the same
offset would apply.

You can either have sense 1 (just a tzoffset), and no date/time
computations, or you can have date/time computations with sense 2.
Note that naive time is a special case of sense 2: the tzinfo object
raises an exception whenever you ask it for an offset.

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