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

[Guido van Rossum]

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

I looked at the code, but I couldn't find where it does conversion
between arbitrary timezones -- almost all timezone-related code seems
to have to do with parsing timezone names and specifications.

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

A goal of the new datetime module is to avoid all dependency on the C
library's time facilities -- we must support calculataions outside the
range that the C library can deal with.

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

Ditto.

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