We seem to have added tzset() gimmicks to CVS Python. test_time now fails on Windows, simply because time.tzset raises AttributeError there. Now Windows does support tzset(), but not TZ values of the form test_time.test_tzset() is testing, like environ['TZ'] = 'US/Eastern' and environ['TZ'] = 'Australia/Melbourne' The rub here is that I haven't found *any* tzset man pages on the web that claim TZ accepts such values (other than to silently ignore them because they're not in a recognized format). The POSIX defn is typical: http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html and search down for TZ. There's no way to read that as supporting the values we're testing. Anyone have a clue? not-all-pits-should-be-dived-into-ly y'rs - tim
On Saturday, March 15, 2003, at 02:00 PM, Tim Peters wrote:
We seem to have added tzset() gimmicks to CVS Python.
That was my patch.
test_time now fails on Windows, simply because time.tzset raises AttributeError there.
test_time.test_tzset should only be run if time.tzset is defined (which should only be there if configure determines that tzset works with the TZ formats we are testing). Feel like adding a clause at the top of test_tzset to skip the test if time.tzset is not defined, or should I submit a patch?
Now Windows does support tzset(), but not TZ values of the form test_time.test_tzset() is testing, like
environ['TZ'] = 'US/Eastern' and environ['TZ'] = 'Australia/Melbourne'
The rub here is that I haven't found *any* tzset man pages on the web that claim TZ accepts such values (other than to silently ignore them because
It specifies the pathname to a tzfile(5) format file, relative to a OS defined default. From BSD: If its value does not begin with a colon, it is first used as the path- name of a file (as described above) from which to read the time conver- sion information. If that file cannot be read, the value is then inter- preted as a direct specification (the format is described below) of the time conversion information. Solaris has a similar definition. Linux documents this format as needing to start with a ':' but accepts it (at least I think I tested this...) To me, this is the useful format as all the others require you to know your DST transition times rather rely of the OS to supply them. At the moment if the 'path to a tzfile(5)' format is not accepted, your tzset(3) is considered broken and time.tzset not built. I'm happy to rewrite the detection in configure.in and the test in test_time.py to lower the bar on this, but I think a better solution may be to determine if Windows has a format that lets us to DST calculations and keep the bar high. I was hoping that such a format would a) exist and b) Allow translation between the Unix standard of Country/Region to whatever-windows-uses.
not-all-pits-should-be-dived-into-ly y'rs - tim
but-i-was-pushed-by-those-damn-politicans-ly y'rs -- Stuart Bishop <zen@shangri-la.dropbear.id.au> http://shangri-la.dropbear.id.au/
[Stuart Bishop] <snip>
I'm happy to rewrite the detection in configure.in and the test in test_time.py to lower the bar on this, but I think a better solution may be to determine if Windows has a format that lets us to DST calculations and keep the bar high. I was hoping that such a format would a) exist and b) Allow translation between the Unix standard of Country/Region to whatever-windows-uses.
If there is one thing I have learned from writing _strptime is that you cannot be strict in the slightest for your input when it comes to time-based data. I think this is another case where you need to be loose about input and strict with output. -Brett
[Brett Cannon]
If there is one thing I have learned from writing _strptime is that you cannot be strict in the slightest for your input when it comes to time-based data. I think this is another case where you need to be loose about input and strict with output.
Python doesn't do anything with TZ's value -- it doesn't even look to see whether TZ is set, let alone parse it (well, Python's obsolete tzparse module parses TZ's value, but the new code in question does not). The cross-platform semantics of TZ are a joke. The tests we have rely on non-standard extensions (viewing POSIX as the only definitive std here). Even if they stuffed colons at the front, POSIX leaves the interpretation of colon-initiated TZ values entirely up to the implementation: If TZ is of the first format (that is, if the first character is a colon), the characters following the colon are handled in an implementation-defined manner. Worse, if the platform tzset() isn't happy with TZ's value, it has no way to tell you: the function is declared void, and has no defined effects on errno. I hope the community takes up the challenge of building a sane cross-platform time zone facility building on 2.3 datetime's tzinfo objects.
[Tim Peters]
The cross-platform semantics of TZ are a joke. The tests we have rely on non-standard extensions (viewing POSIX as the only definitive std here). Even if they stuffed colons at the front, POSIX leaves the interpretation of colon-initiated TZ values entirely up to the implementation:
If TZ is of the first format (that is, if the first character is a colon), the characters following the colon are handled in an implementation-defined manner.
Worse, if the platform tzset() isn't happy with TZ's value, it has no way to tell you: the function is declared void, and has no defined effects on errno.
If this thing is so broken, why are we bothering with it? It's one thing to want to give people access to facilities that do something useful; it's another thing entirely to give them access to something that is broken. Perhaps if we are going to bother to make this available the work should be done to make it have more standard output? So take whatever the C function returns and then make it conform to some reasonable output. -Brett
If this thing is so broken, why are we bothering with it? It's one thing to want to give people access to facilities that do something useful; it's another thing entirely to give them access to something that is broken.
Perhaps if we are going to bother to make this available the work should be done to make it have more standard output? So take whatever the C function returns and then make it conform to some reasonable output.
I look at it differently. It's useful to make the platform tzset() available, because it lets us do something that couldn't be done before: change the definition of local time without restarting Python. If tzset() doesn't take standardized arguments, that's the problem of whoever wants to use it. There are lots of functions that have this: for example, anything taking a filename. At least it's there. The test suite for tzset() probably is too strict; we'll tune it to avoid failures on common platforms during the beta cycle. I don't know if it makes sense to provide tzset() on Windows; from Tim's description it doesn't sound likely. --Guido van Rossum (home page: http://www.python.org/~guido/)
[Guido]
... I don't know if it makes sense to provide tzset() on Windows; from Tim's description it doesn't sound likely.
I wouldn't object if someone else wanted to do the work (which includes documenting it well enough to cut off an endless stream of obvious questions). The Windows tzset is weak but maybe usable for some people. For example, time zone names must be exactly 3 characters, and you can't tell the Windows tzset when daylight time begins or ends: it uses US rules no matter what the time zone. The native Win32 SetTimeZoneInformation() doesn't suffer these idiocies, but I'm not sure whether calling that affects the Unixish _tzname (etc) variables. "Doing the work" also means figuring out all that stuff.
On Monday, March 17, 2003, at 01:17 PM, Tim Peters wrote:
[Guido]
... I don't know if it makes sense to provide tzset() on Windows; from Tim's description it doesn't sound likely.
I wouldn't object if someone else wanted to do the work (which includes documenting it well enough to cut off an endless stream of obvious questions). The Windows tzset is weak but maybe usable for some people. For example, time zone names must be exactly 3 characters, and you can't tell the Windows tzset when daylight time begins or ends: it uses US rules no matter what the time zone. The native Win32 SetTimeZoneInformation() doesn't suffer these idiocies, but I'm not sure whether calling that affects the Unixish _tzname (etc) variables. "Doing the work" also means figuring out all that stuff.
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. -- Stuart Bishop <zen@shangri-la.dropbear.id.au> http://shangri-la.dropbear.id.au/
On Thursday, March 20, 2003, at 04:01 PM, Stuart Bishop wrote:
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. 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. 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 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). - 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. -- Stuart Bishop <zen@shangri-la.dropbear.id.au> http://shangri-la.dropbear.id.au/
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/)
[Guido]
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.
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 as the test expects.
You can read the docs. It doesn't work on Windows the way anyone expects <0.5 wink>: http://tinyurl.com/9a2n
... 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 warnings.
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 warnings.
I guess we shouldn't expose the Windows version of tzset() at all. The syntax it accepts and the rules it applies (always following US DST rules) make it pretty useless. OTOH I think tzset() is useful on most Unix and Linux platforms, and there's no easy alternative (short of wrapping the tz library, which would be a huge task), so there we should expose it. I believe this means that Stuart's patch can be checked in as is. We can tweak it based on reports during the beta cycle. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Sunday, March 16, 2003, at 04:07 PM, Tim Peters wrote:
Worse, if the platform tzset() isn't happy with TZ's value, it has no way to tell you: the function is declared void, and has no defined effects on errno.
Yup. It sucks, but is the best there is. I can't even find proprietary solutions for various Unix flavours. Maybe a post to Slashdot saying Zope 3 will be Windows only due to limitations in POSIX would at least get something for the free distros :-)
I hope the community takes up the challenge of building a sane cross-platform time zone facility building on 2.3 datetime's tzinfo objects.
A cross-platform time zone facility isn't a problem - the data we need is available and maintained as part of numerous free Unix distributions. We could even steal C code to decode it if we are particularly lazy. The trick is that updates to coutries' timezone changes don't follow the Python release schedule, and I think this was covered in depth on python-dev not long ago in excruciating details that I'm sure no one wants to repeat :-) So the actual problem would be how to distribute data file updates to Python installations, which would also mean we could support the various ISO standards relating to things like country codes and languages (which I'm sure many of us are currently doing manually). Possibly a script that could be run as the user-who-owns-the-python-installation to update from source forge, which python-announce as the notification channel when files are updated? -- Stuart Bishop <zen@shangri-la.dropbear.id.au> http://shangri-la.dropbear.id.au/
Stuart Bishop wrote:
On Sunday, March 16, 2003, at 04:07 PM, Tim Peters wrote:
Worse, if the platform tzset() isn't happy with TZ's value, it has no way to tell you: the function is declared void, and has no defined effects on errno.
Yup. It sucks, but is the best there is. I can't even find proprietary solutions for various Unix flavours. Maybe a post to Slashdot saying Zope 3 will be Windows only due to limitations in POSIX would at least get something for the free distros :-)
I wonder why we need a TZ-parser then ? If it's non-standard anyway, the module is probably better off outside the core as separate download from e.g. SF.
I hope the community takes up the challenge of building a sane cross-platform time zone facility building on 2.3 datetime's tzinfo objects.
A cross-platform time zone facility isn't a problem - the data we need is available and maintained as part of numerous free Unix distributions. We could even steal C code to decode it if we are particularly lazy.
-1 Why bloat the Python distribution with yet another locale implementation ? -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Mar 17 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
Python UK 2003, Oxford: 15 days left EuroPython 2003, Charleroi, Belgium: 99 days left
A cross-platform time zone facility isn't a problem - the data we need is available and maintained as part of numerous free Unix distributions. We could even steal C code to decode it if we are particularly lazy.
-1
Why bloat the Python distribution with yet another locale implementation ?
Agreed. This should be a 3rd party add-on. (Especially since in many cases, tzset() does all you need.) --Guido van Rossum (home page: http://www.python.org/~guido/)
[Stuart Bishop]
Yup. It sucks, but is the best there is. I can't even find proprietary solutions for various Unix flavours. Maybe a post to Slashdot saying Zope 3 will be Windows only due to limitations in POSIX would at least get something for the free distros :-)
[M.-A. Lemburg]
I wonder why we need a TZ-parser then ? If it's non-standard anyway, the module is probably better off outside the core as separate download from e.g. SF.
TZ parsing code hasn't been added to Python, just a wrapper around the platform tzset() function (if any, and for now ignoring the flavor of tzset supplied by Windows). POSIX defines various forms TZ values can take. Some forms have portable meaning across POSIX systems, while others do not.
I hope the community takes up the challenge of building a sane cross-platform time zone facility building on 2.3 datetime's tzinfo objects.
A cross-platform time zone facility isn't a problem - the data we need is available and maintained as part of numerous free Unix distributions. We could even steal C code to decode it if we are particularly lazy.
-1
Why bloat the Python distribution with yet another locale implementation ?
Well, I didn't say anything about the std distribution. Whether there or elsewhere, Python didn't and doesn't have any portable (x-platform) way to deal with time zones. 2.3's tzinfo objects are capable of carrying time zone information in a sane x-platform way, but no concrete tzinfo objects are supplied.
[Stuart]
test_time.test_tzset should only be run if time.tzset is defined (which should only be there if configure determines that tzset works with the TZ formats we are testing). Feel like adding a clause at the top of test_tzset to skip the test if time.tzset is not defined, or should I submit a patch?
Done. [Tim]
Now Windows does support tzset(), but not TZ values of the form test_time.test_tzset() is testing, like
environ['TZ'] = 'US/Eastern' and environ['TZ'] = 'Australia/Melbourne'
The rub here is that I haven't found *any* tzset man pages on the web that claim TZ accepts such values (other than to silently ignore them because
It specifies the pathname to a tzfile(5) format file, relative to a OS defined default. From BSD: If its value does not begin with a colon, it is first used as the pathname of a file (as described above) from which to read the time conversion information. If that file cannot be read, the value is then interpreted as a direct specification (the format is described below) of the time conversion information. Solaris has a similar definition. Linux documents this format as needing to start with a ':' but accepts it (at least I think I tested this...)
To me, this is the useful format as all the others require you to know your DST transition times rather rely of the OS to supply them. At the moment if the 'path to a tzfile(5)' format is not accepted, your tzset(3) is considered broken and time.tzset not built.
I'm happy to rewrite the detection in configure.in and the test in test_time.py to lower the bar on this, but I think a better solution may be to determine if Windows has a format that lets us to DST calculations and keep the bar high. I was hoping that such a format would a) exist and b) Allow translation between the Unix standard of Country/Region to whatever-windows-uses.
Nevertheless I don't think that the standard definition for tzset() defines which values will be accepted by a particular tzset implementation. So a test that relies on these is bound to fail on systems, not because tzset is broken, but because the test makes unfair assumptions. Perhaps you can rewrite the test to use only standardized input forms? --Guido van Rossum (home page: http://www.python.org/~guido/)
[Stuart Bishop]
... To me, this is the useful format as all the others require you to know your DST transition times rather rely of the OS to supply them.
But since there are no defined names in POSIX, supplying transition rules explicitly via the second POSIX format is the only way that has a shot at being portable.
At the moment if the 'path to a tzfile(5)' format is not accepted, your tzset(3) is considered broken and time.tzset not built.
I'll let the Unix weenies straighten out their own mess here <wink>.
I'm happy to rewrite the detection in configure.in and the test in test_time.py to lower the bar on this, but I think a better solution may be to determine if Windows has a format that lets us to DST calculations and keep the bar high.
I couldn't parse that, but I've got no interest in exposing the Windows version of tzset() to Python users regardless (it's a lame effort to mimic part of the Unixish TZ gimmicks; the Win32 API has a richer way to deal with time zones, which doesn't use environment variables).
participants (5)
-
Brett Cannon -
Guido van Rossum -
M.-A. Lemburg -
Stuart Bishop -
Tim Peters