This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients Rioky, amaury.forgeotdarc, belopolsky, lemburg
Date 2011-11-24.10:49:01
SpamBayes Score 7.1054274e-15
Marked as misclassified No
Message-id <4ECE210A.5030504@egenix.com>
In-reply-to <1322130688.2.0.565362365512.issue13466@psf.upfronthosting.co.za>
Content
Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa@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.
History
Date User Action Args
2011-11-24 10:49:04lemburgsetrecipients: + lemburg, amaury.forgeotdarc, belopolsky, Rioky
2011-11-24 10:49:01lemburglinkissue13466 messages
2011-11-24 10:49:01lemburgcreate