Message148212
| Author |
amaury.forgeotdarc |
| Recipients |
Rioky, amaury.forgeotdarc, belopolsky, lemburg |
| Date |
2011年11月23日.23:17:34 |
| SpamBayes Score |
2.7679525e-12 |
| Marked as misclassified |
No |
| Message-id |
<1322090255.57.0.5529039197.issue13466@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> 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) |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2011年11月23日 23:17:35 | amaury.forgeotdarc | set | recipients:
+ amaury.forgeotdarc, lemburg, belopolsky, Rioky |
| 2011年11月23日 23:17:35 | amaury.forgeotdarc | set | messageid: <1322090255.57.0.5529039197.issue13466@psf.upfronthosting.co.za> |
| 2011年11月23日 23:17:35 | amaury.forgeotdarc | link | issue13466 messages |
| 2011年11月23日 23:17:34 | amaury.forgeotdarc | create |
|