The time.tzset() function is not included in Solaris
builds, because the code in configure.in that checks
for the existence of tzset() relies on struct tm having
a tm_zone member - which Solaris does not have (at
least not up to 2.8).

The attached patch to configure.in allows Solaris to
detect the existence of tzset() and Python builds OK,
and the resulting time.tzset() function seems to work
just fine.

diff -u configure.in.DIST configure.in
--- configure.in.DIST   2005-01-05 16:25:24.830001000 +1100
+++ configure.in        2005-01-05 16:25:38.227000000 +1100
@@ -2912,10 +2912,6 @@
        tzset();
        if (localtime(&groundhogday)->tm_hour != 11)
            exit(1);
-       if (strcmp(localtime(&groundhogday)->tm_zone,
"AEDT"))
-           exit(1);
-       if (strcmp(localtime(&midyear)->tm_zone, "AEST"))
-           exit(1);
 
        exit(0);
 }

Logged In: YES 
user_id=357491

But that fix removes a sanity check to detect broken tzset 
implementations.

Is there a similar way to check on Solaris to make sure tzset is not 
broken?  If so resubmit a patch (I reclassified this tracker item 
appropriately) that makes the test conditional on Solaris. 

Logged In: YES 
user_id=293157

Hmm, I'm no autoconf guru, but try the attached patch.  It
seems to do the right thing on Solaris (tzset but no
tm_zone) and FreeBSD (tzset and tm_zone).

Amazing what you can find with half an hour of Google!

Logged In: YES 
user_id=293157

I've added  second patch with more comprehensive diffs that
also checks whether tzset() affects tzname[] (for those
systems without tm_zone).  This may be considered overkill!

Logged In: YES 
user_id=357491

Well, considering tzset can be called when HAVE_TZNAME is set it 
definitely does not hurt to check it.

The patch basically looks good, but I don't have time right now for a 
thorough check so I am not going to check it in right away.  But it will 
get in.

Logged In: YES 
user_id=357491

For configure.in, rev. 1.481 in 2.5 and rev. 1.475.2.6 in 2.4 have the fix.  
Only modified the comments of your patch.

Thanks, Gregory!