[Zope3-dev] RE: [Python-Dev] Holes in time

[Tim Peters]

[M.-A. Lemburg]
> The only right way to deal with these problems is to raise
> ValueErrors.

That was one of the presented alternatives, yes <wink>.

> Calculations resulting in these local times are
> simply doomed and should be done in UTC instead.

That one isn't the issue here:  DST-aware calculations under the datetime
module indeed *must* convert to UTC (or some other fixed reference).
Arithmetic within a single time zone is "naive" under datetime, doing no
adjustments whatsoever to the date and time fields you'd expect if you had
no notion of time zone.

The question is what happens when you get a final result in UTC (or other
fixed reference), try to convert it back to your local time zone, and the
astimezone() method deduces it's the hour at the end of DST that can't be
spelled in local time.

> DST and local times are not mathematical properties, so you
> shouldn't expect them to behave in that way.

They *have* mathemetical properties, though, and very simple ones at that.
The difficulty is that they're not complicated enough to give the illusion
of meeting naive expectations <wink>.

> For some fun reading have a look at the tzarchive package docs at:
> ftp://elsie.nci.nih.gov/pub/

time zones are compressed dicts.