[issue13466] new timezones

Marc-Andre Lemburg report at bugs.python.org
Thu Nov 24 11:49:03 CET 2011


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
>>> But that does not give the *other* timezone :-(
>> Which other timezone ?
> I meant the other timezone *name*.
> 
> I think we don't understand each other:
> - time.timezone is the offset of the local (non-DST) timezone.
> - time.altzone is the offset of local DST timezone.

Yes, I know.

> They don't depend on the current date, they depend only on the timezone database.
> localtime() only gives the timezone for a given point in time, and the time module needs to present two timezones.

Right, but they should only depend on the data in the timezone
database at the time of import of the module and not determine
the values by looking at specific dates in the past.

The only problem is finding out whether the locale uses DST in
case the current import time points to a non-DST time. This can
be checked by looking at Jan 1st and June 1st after
the current import time (ie. in the future) and then testing
tm_isdst. If there is a DST change, then you set
time.altzone = time.timezone - 3600. Otherwise, you set
time.altzone = time.timezone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13466>
_______________________________________


More information about the Python-bugs-list mailing list