Message226970
I don't think there is anything we can do here. Without a TZ database, Python has to rely on time.tzname which in case of TZ=Europe/Moscow returns
>>> time.tzname
('MSK', 'MSK')
Hardcoding a timezones dictionary as done in email module may work for a handful of American timezones, but will not work for TZ's like Europe/Moscow.
$ zdump -v Europe/Moscow| tail
Europe/Moscow Sat Oct 24 22:59:59 2009 UTC = Sun Oct 25 02:59:59 2009 MSD isdst=1
Europe/Moscow Sat Oct 24 23:00:00 2009 UTC = Sun Oct 25 02:00:00 2009 MSK isdst=0
Europe/Moscow Sat Mar 27 22:59:59 2010 UTC = Sun Mar 28 01:59:59 2010 MSK isdst=0
Europe/Moscow Sat Mar 27 23:00:00 2010 UTC = Sun Mar 28 03:00:00 2010 MSD isdst=1
Europe/Moscow Sat Oct 30 22:59:59 2010 UTC = Sun Oct 31 02:59:59 2010 MSD isdst=1
Europe/Moscow Sat Oct 30 23:00:00 2010 UTC = Sun Oct 31 02:00:00 2010 MSK isdst=0
Europe/Moscow Sat Mar 26 22:59:59 2011 UTC = Sun Mar 27 01:59:59 2011 MSK isdst=0
Europe/Moscow Sat Mar 26 23:00:00 2011 UTC = Sun Mar 27 03:00:00 2011 MSK isdst=0
Europe/Moscow Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 07:14:07 2038 MSK isdst=0
Europe/Moscow Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 07:14:07 2038 MSK isdst=0
(And it looks like the planned for 2014-10-26 switch back to winter time is not in my laptop's database yet.) |
|
Date |
User |
Action |
Args |
2014-09-17 01:12:31 | belopolsky | set | recipients:
+ belopolsky, lemburg, akira |
2014-09-17 01:12:31 | belopolsky | set | messageid: <1410916351.38.0.0447958118309.issue22426@psf.upfronthosting.co.za> |
2014-09-17 01:12:31 | belopolsky | link | issue22426 messages |
2014-09-17 01:12:30 | belopolsky | create | |
|