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

[M.-A. Lemburg]

Guido van Rossum wrote:
> Let me present the issue differently.
> 
> On Sunday, Oct 27, 2002, both 5:30 UTC and 6:30 UTC map to 1:30 am US
> Eastern time: 5:30 UTC maps to 1:30 am EDT, and 6:30 UTC maps to 1:30
> am EST.  (UTC uses a 24 hour clock.)
> 
> We have a tzinfo subclass representing the US Eastern (hybrid)
> timezone whose primary responsibility is to translate from local time
> in that timezone to UTC: Eastern.utcoffset(dt).  It can also tell us
> how much of that offset is due to DST: Eastern.dst(dt).
> 
> It is crucial to understand that with "Eastern" as tzinfo, there is
> only *one* value for 1:30 am on Oct 27, 2002.  The Eastern tzinfo
> object arbitrarily decides this is EDT, so it maps to 5:30 UTC.  (But
> the problem would still exist if it arbitrarily decided that it was
> EST.)
> 
> It is also crucial to understand that we have no direct way to
> translate UTC to Eastern.  We only have a direct way to translate
> Eastern to UTC (by subtracting Eastern.utcoffset(dt)).

Why don't you take a look at how this is done in mxDateTime ?
It has support for the C lib API timegm() (present in many C libs)
and includes a work-around which works for most cases; even close
to the DST switch time.

BTW, you should also watch out for broken mktime() implementations
and whether the C lib support leap seconds or not. That has bitten
me a few times too.

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