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:
> This version should only build time.tzset if it accepts the TZ
> variable formats documented at:
> 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
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
core dump. The code that populated time.tzname etc. has never had
tests before, so its not like we are going backwards. This option
means tzset(3) could be exposed on Windows (which I can't
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
TZ environment variable format *and* can correctly do daylight
time calculations in the southern hemisphere etc.
Stuart Bishop <email@example.com>