[Python-Dev] tzset

[Guido van Rossum]

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

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