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

[M.-A. Lemburg]

Tim Peters wrote:
> We still have two time zone conversion problems, and always will (they come
> with the territory -- they're inherent problems, not artifacts of the
> implementation).  They only arise in a tzinfo class that's trying to model
> both standard and daylight time.  In effect, that's one class trying to
> pretend it's two different time zones, and at the transition points there
> are "impossible problems".
> ...
> UTC, EST and EDT are all self-consistent and trivial.  It's only wall time
> that's a problem, and only at the transition points:
> 
> 1. When DST starts (the "wall start" line), the wall clock leaps from 1:59
> to 3:00.  A wall time of the form 2:MM doesn't really make sense on that
> day.  The example classes do what I believe is the best that can be done:
> since 2:MM is "after 2" on that day, it's taken as daylight time, and so as
> an alias for 1:MM standard == 1:MM wall on that day, which is a time that
> does make sense on the wall clock that day.  The astimezone() function
> ensures that the "impossible hour" on that day is never the result of a
> conversion (you'll get the standard-time spelling instead).  If you don't
> think that's the best that can be done, speak up now.
> 
> 2. When DST ends (the "wall end" line), we have a worse problem:  there'a an
> hour that can't be spelled *at all* in wall time.  It's the hour beginning
> at the moment DST ends; in the example, that's times of the form 6:MM UTC on
> the day daylight time ends.  The local wall clock leaps from 1:59 (daylight
> time) back to 1:00 again (but the second time as a standard time).  The hour
> 6:MM UTC looks like 1:MM, but so does the hour 5:MM UTC on that day.  A
> reasonable tzinfo class should take 1:MM as being daylight time on that day,
> since it's "before 2".  As a consequence, the hour 6:MM UTC has no
> wall-clock spelling at all.

The only right way to deal with these problems is to raise
ValueErrors. Calculations resulting in these local times are
simply doomed and should be done in UTC instead. DST
and local times are not mathematical properties, so you
shouldn't expect them to behave in that way. For some fun
reading have a look at the tzarchive package docs at:
ftp://elsie.nci.nih.gov/pub/


-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
_______________________________________________________________________
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/