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