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

[M.-A. Lemburg]

Guido van Rossum wrote:
>>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 doesn't do conversion between time zone, but it does provide
you with the offset information from UTC to local time in
both directions.

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

I don't see how that can be done for time zones and DST.

Timezones and even more the DST settings change more often
for various locales than you think, so assumptions about the
offset between UTC and local time for the future as well as
for historical dates can easily be wrong. The tz
data used by most C libs has tables which account for many
of the known offsets in the past; they can only guess about
the future.

The only usable time scale for historic and future date/time
is UTC. The same is true if you're interested in date/time
calculations in terms of absolute time.

Now, for current time zones, the C lib is a good source
of information, so I don't see why you wouldn't want to
use it.

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

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