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

[Tim Peters]

[Patrick K. O'Brien]
> ...
> Would it help any to store the basic timezone (25 timezones that
> ignore DST, like GMT) separate from some kind of DST boolean/offset
> (assuming DST is always a one hour offset)?

Alas, it's not.

> So we would never store "EDT", we would instead store "EST" with DST
> as True, or as GMT-5 with DST as True. Then local time would be the
> basic timezone plus the DST. Syntactic sugar-coating could display
> "EST" with DST == 1 as "EDT".

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, and because DST was lumped in with TZ it
seemed impossible to untangle the two; as you suggested elsewhere, the TZ
code *without* DST was quite well developed, predictable, and explainable).
I've noted a caution several times now that ECMAScript does not mix the two
(TZ and DST adjustments are kept separate), and the C99 struct tmx saves a
distinct number-of-minutes DST offset field too.

I don't know why.  Their respective rationales don't spell it out, and so
far the only "use case" we've seen here for DST is to complain about it
<wink>.  But that we already got in trouble mixing the two doesn't make me
confident that we actually know more than they do.

BTW, Common Lisp also keeps TZ and DST separate, although CL has been
criticized for leaving the effect of DST essentially undefined:

    http://www-2.cs.cmu.edu/Groups/AI/html/cltl/clm/node232.html

One ray of hope from that page:

    There appears to be no user demand for floating-point time zones.

there-goes-my-job-security<wink>-ly y'rs  - tim