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

[Wade Leftwich]

On Friday 15 March 2002 19:03, Tim Peters wrote:
> [Patrick K. O'Brien]
>
> >=A0...
> >=A0Would it help any to store the basic timezone (25 timezones that
> >=A0ignore DST, like GMT) separate from some kind of DST boolean/offset
> >=A0(assuming DST is always a one hour offset)?
>
> Alas, it's not.
>
> >=A0So we would never store "EDT", we would instead store "EST" with DS=
T
> >=A0as True, or as GMT-5 with DST as True. Then local time would be the
> >=A0basic timezone plus the DST. Syntactic sugar-coating could display
> >=A0"EST" with DST =3D=3D 1 as "EDT".
>
> Guido doesn't like this, but I expect your basic intuition is correct: =
=A0DST
> is not part of timezone, and indeed we already got ourselves into troub=
le
> by mixing the two into a single tzoffset field (that's basically why *a=
ll*
> the tz code got thrown out of the prototype: =A0it wasn't clear what th=
e heck
> it was doing across DST switches,

I think there are two senses in which 'timezone' and 'DST' are used.

1. Simple. A timezone is an offset from GMT. A timezone that switches to =
DST=20
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=20
set their clocks the same way. So in the eastern United States, in the=20
wintertime your time zone (sense 1) is EST, and in the summer it's (sense=
 1)=20
EDT. Unless you are in Indiana, where they stay on EST year-round. (The=20
Windows control panel gives you a separate selection for Indiana when you=
 go=20
to set the date and time.)

In the shared-calendar use case, data supplied by the clients can always =
have=20
sense 1. (Right now in Ithaca NY it is 19:23 EST.) It's when you go to=20
schedule a meeting for this coming summer that you get into trouble. 2400=
=20
hours from now it will be 20:23 EDT on June 23. In Indiana they will call=
 it=20
19:23 EST.

It seems to me that it is reasonable for a datetime class to support sens=
e 1.=20
Sense 2 is the application's responsibility: Fred is in Indiana, so on hi=
s=20
calendar the Fourth of July conference call is at 10 o'clock EST, while f=
or=20
the people in NYC it starts at 11 EDT. The application has to know whethe=
r or=20
not a client observes daylight savings time. And if different zones sprin=
g=20
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=20
timezone property. EDT and EST are different timezones. EDT is represente=
d in=20
the datetime object as (-4, 'EDT') and EST as (-5, 'EST').

-- Wade Leftwich
Ithaca, NY