> > 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4