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 :-( > 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. That's why the current implementation uses "absolute" dates like the of January: DST changes are often in March and October. 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 - 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) ---------- _______________________________________ 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
