[Python-Dev] tzset

Stuart Bishop zen@shangri-la.dropbear.id.au
Fri, 11 Apr 2003 06:35:07 +1000


On Thursday, March 20, 2003, at 04:01  PM, Stuart Bishop wrote:

> I've submitted an update to SF:
> 	http://www.python.org/sf/706707
>
> This version should only build time.tzset if it accepts the TZ 
> environment
> variable formats documented at:
> 	http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html
> So it shouldn't build under Windows.
>
> The last alternative would be to expose time.tzset if it exists at all,
> and the test suite would simply check to make sure it doesn't raise
> an exception. This would leave behaviour totally up to the OS, and the
> corresponding lack of documentation in the Python library reference.

The time.tzset patch is running fine. The outstanding issue is the
test suite. I can happily run the existing tests on OS X, Redhat 7.2
and Solaris 2.8, but there are reports of odd behaviour that can
only be attributed (as far as I can see) to broken time libraries.

Broken time libraries are fine - time.tzset() is at a basic level
just a wrapper around the C library call and we can't take 
responsibility
for the operating system's bad behavior. However, if the C library
doesn't work as documented, we have no way of testing if the various
time.* values are being updated correctly.

I think these are the options:
     - Use the test suite as it stands at the moment, which may cause the
       test to fail on broken platforms.
     - Use the test suite as it stands at the moment, flagging this test
       as an expected failure on broken platforms.
     - Don't test - just make sure time.tzset() doesn't raise an 
exception or
       core dump. The code that populated time.tzname etc. has never had 
unit
       tests before, so its not like we are going backwards. This option
       means tzset(3) could be exposed on Windows (which I can't 
presently
       do, not having a Windows dev box available).
     - Make the checks for a sane tzset(3) in configure.in more paranoid,
       so time.tzset() is only built if your OS correctly parses the 
standard
       TZ environment variable format *and* can correctly do daylight 
savings
       time calculations in the southern hemisphere etc.

-- 
Stuart Bishop <zen@shangri-la.dropbear.id.au>
http://shangri-la.dropbear.id.au/