Marc-Andre Lemburg <m...@egenix.com> added the comment: Amaury Forgeot d'Arc wrote: > > Amaury Forgeot d'Arc <amaur...@gmail.com> added the comment: > >> A fairly "correct" way is to query the time zone database at time module >> import time by using the DST and GMT offset of that time. > > But that does not give the *other* timezone :-(
Which other timezone ? You set time.timezone to the GMT offset of the import time and then subtract another 3600 seconds in case tm_isdst is set. >> IMO time.timezone and time.daylight should be deprecated since they >> will give wrong results around DST changes (both switch times and >> legal changes such as the described one) in long running processes >> such as daemons. > > time.timezone is the non-DST timezone: this value does not change around > the DST change date. No, but time.daylight changes and time.timezone can change in situations like these where a region decides to change the way DST is dealt with, e.g. switches to the DST timezone or moves the switchover date. Since both values are tied to a specific time I don't think it's a good idea to have them as module globals. > That's why the current implementation uses "absolute" > dates like the of January: DST changes are often in March and October. Such an algorithm can be used as fallback solution in case tm_isdst is -1 (unknown), but not in case the DST information is available. > What about this algorithm: > - pick the first of January and the first of July surrounding the current date > - if both have tm_idst==0, the region has no DST. Use the current GMT offset > for > both timezone and altzone; daylight=0 Those two steps are not necessary. If tm_isdst == 0, you already know that the current time zone is not DST. > - otherwise, use the *current* time and get its DST and GMT offset. This is > enough > to compute both timezone and altzone (with the relation altzone=timezone-3600) That's what I suggested above. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13466> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
