Thu, 10 Apr 2003 23:52:43 -0400
> 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
> That *could* be construed as a bug in the test, because the C library
> docs only promise that the daylight variable is nonzero.
That's all the MS docs promise too. You're actually getting ord("E"), the
first letter in "EDT".
> 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
> test expects.
You can read the docs. It doesn't work on Windows the way anyone expects
> But is the observed behavior on Windows broken or not? I don't know.
It probably works as documented, but Real Windows Weenies use the native
Win32 time zone functions.
> 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.
It's not really what I want. When we expose highly platform-dependent
functions, we create a lot of confusion along with them. Perhaps that's
because we're not always careful to emphasize that the behavior is a
cross-platform crapshoot, and users are rarely careful to heed such