Looking into the unit tests on windows I have found a few interesting points to share.
Since there is no time.tzset() on widnows, which is automatically called by python, setting TZ does nothing. However, setting TZ variable before running python does appear to have an effect so the python code must have a special Windows case on startup. NOTE: For this case only 3 letter tznames work e.g. TZ=PST8PDT or TZ=EST-10EDT (Tried playing with CRT _tzset() but no luck there. Specifically, the day night transition test in weeutil fails as the timezone cannot be set on the fly. What I did find is probably a Windows CRT and/or Python bug in datetime deltas across DST boundaires. >>> import weeutil >>> import time >>> start=time.mktime((2013,11,3, 0,0,0,0,0,-1)) >>> stop=time.mktime((2013,11,3, 6,0,0,0,0,-1)) >>> for s in weeutil.intervalgen(start,stop,1800): ... print s ... [2013-11-03 00:00:00 PDT (1383462000) -> 2013-11-03 00:30:00 PDT (1383463800 )] [2013-11-03 00:30:00 PDT (1383463800) -> 2013-11-03 01:00:00 PST (1383469200 )] [2013-11-03 01:00:00 PST (1383469200) -> 2013-11-03 01:30:00 PST (1383471000 )] [2013-11-03 01:30:00 PST (1383471000) -> 2013-11-03 02:00:00 PST (1383472800 )] [2013-11-03 02:00:00 PST (1383472800) -> 2013-11-03 02:30:00 PST (1383474600 )] [2013-11-03 02:30:00 PST (1383474600) -> 2013-11-03 03:00:00 PST (1383476400 )] [2013-11-03 03:00:00 PST (1383476400) -> 2013-11-03 03:30:00 PST (1383478200 )] [2013-11-03 03:30:00 PST (1383478200) -> 2013-11-03 04:00:00 PST (1383480000 )] [2013-11-03 04:00:00 PST (1383480000) -> 2013-11-03 04:30:00 PST (1383481800 )] [2013-11-03 04:30:00 PST (1383481800) -> 2013-11-03 05:00:00 PST (1383483600 )] [2013-11-03 05:00:00 PST (1383483600) -> 2013-11-03 05:30:00 PST (1383485400 )] [2013-11-03 05:30:00 PST (1383485400) -> 2013-11-03 06:00:00 PST (1383487200 )] intervalgen is just using a loop and adding intervals to datetime objects. It has done the DST end too early. I found this by the errors in weeutil unit test. Interesting....
