Prev: Wing IDE 3.2.9 released: Fixes debugger for Python 2.4.x and earlier
Next: Installing Python 3.1.2 from source, how do you resolve the sqlite3-dev dependency?
From: Chris Withers on 16 Jun 2010 11:30 Hi All, I'd like to make test_non_gmt_timezone at the bottom of https://secure.simplistix.co.uk/svn/Simplistix/testfixtures/branches/1.8/testfixtures/tests/test_time.py run on Windows, any suggestions? cheers, Chris
From: Nobody on 16 Jun 2010 15:54 On Wed, 16 Jun 2010 16:30:02 +0100, Chris Withers wrote: > I'd like to make test_non_gmt_timezone at the bottom of > https://... > run on Windows, any suggestions? MSVCRT has _tzset(), which understands the TZ environment variable. http://msdn.microsoft.com/en-us/library/90s5c885%28VS.80%29.aspx For whatever reason, tython's "time" module doesn't provide the tzset() function on Windows. However, you should be able to use it via ctypes.
From: Chris Withers on 17 Jun 2010 06:45 Nobody wrote: > On Wed, 16 Jun 2010 16:30:02 +0100, Chris Withers wrote: > >> I'd like to make test_non_gmt_timezone at the bottom of >> https://... >> run on Windows, any suggestions? > > MSVCRT has _tzset(), which understands the TZ environment variable. > > http://msdn.microsoft.com/en-us/library/90s5c885%28VS.80%29.aspx > > For whatever reason, tython's "time" module doesn't provide the tzset() > function on Windows. However, you should be able to use it via ctypes. This sounds pretty heavyweight for a unit test. I'm not even sure how I would do this ;-) Where can I find an example? ....or better yet, does anyone have any alternative solutions? Chris
From: Nobody on 18 Jun 2010 20:35
On Thu, 17 Jun 2010 11:45:03 +0100, Chris Withers wrote: >> For whatever reason, tython's "time" module doesn't provide the tzset() >> function on Windows. However, you should be able to use it via ctypes. > > This sounds pretty heavyweight for a unit test. > I'm not even sure how I would do this ;-) from ctypes import cdll tzset = cdll.msvcrt._tzset Except ... Python doesn't appear to use the OS time conversion functions, so calling _tzset() has no effect. And the documentation doesn't specify whether modifying time.timezone is allowed. IOW, I don't think there's any robust way to ask "what would have happened if TZ been set to <whatever> at startup", other than running a separate script with the appropriate TZ setting. You can perform conversions with an explicit timezone using the "datetime" module, but that won't help you test the behaviour of code which uses the "time" module. |