[Python-Dev] tzset (original) (raw)

Guido van Rossum guido@python.org
Thu, 10 Apr 2003 17:35:26 -0400

> 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/xbdchap08.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.

The test passes for me on Red Hat 7.3.

I tried it on Windows, and if I add "#define HAVE_WORKING_TZSET 1" to PC/pyconfig.h, timemodule.c compiles, but the tzset test fails with the error AssertionError: 69 != 1. This is on the line

        self.failUnlessEqual(time.daylight,1)

That could be construed as a bug in the test, because the C library docs only promise that the daylight variable is nonzero. But if I fix that in the test by using bool(time.daylight), I get other failures, so I conclude that tzset() doesn't work the same way on Windows as the test expects.

A simple solution would be to not provide tzset() on Windows. Time on Windows is managed sufficiently different that this might be okay.

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.

But is the observed behavior on Windows broken or not? I don't know.

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.

Right.

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.

But we're not sure if the platform is broken or the test too stringent!

- Use the test suite as it stands at the moment, flagging this test as an expected failure on broken platforms.

Can't do that -- can flag only skipped tests as expected.

- 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).

That would be acceptable to me. Since all we want is a wrapper around the C library tzset(), all we need to test for is that it does that.

- 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.

Sounds like overprotective. I think that in those cases the tzset() function works fine, it's just the database of timezones that's different.

--Guido van Rossum (home page: http://www.python.org/~guido/)