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

[Guido van Rossum]

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

My first guess is that they all figured out that tzoffset alone isn't
enough when you want to do time calculations, and that the problem had
something to do with DST, but then stopped thinking about it further
(perhaps hampered by a US-centric view).

The tm_isdst flag in C's struct tm is useful to disambiguate an
ambiguous local time (the hour in the transition out of DST occurs
twice because the clock is set back).  But the use of the DST offset
that it holds in struct tmx is unclear, and even the combination of
tm_zone and tm_isdst isn't enough to unambiguously determine the DST
transition points (unless you are in the US).

Tzinfo objects can solve these problems because you can write a tzinfo
object that implements any jurisdiction's timezone and DST rules and
history.  See http://www.zope.org/Members/fdrake/DateTimeWiki/TimeZoneInfo

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