On Solaris8, with the WS6U1 compiler, after setting CC
to 'cc -xarch=v9', test_time.py fails with

  File "Lib/test/test_time.py", line 46, in test_mktime
    time.mktime, (999999, 999999, 999999, 999999,
  File
"/vol/marvin-vol8/loewis/python/dist/src/Lib/unittest.py",
line 273, in failUnlessRaises
    raise self.failureException, excName
AssertionError: OverflowError

The problem is that the test doesn't overflow. Instead,
it gives the value 34214554704339.0.

Logged In: YES 
user_id=21627

This was reported for alpha as well, as #538369.

Logged In: YES 
user_id=21627

Assigned to Barry, since Tim assigned #538369 to Barry.

Logged In: YES 
user_id=31435

Raised priority and changed Group to 2.2.1 candidate.  We 
can't assume that time_t is too feeble to represent the 
date being tested, and Barry should rework the test so that 
it doesn't fail on 64-bit boxes (I recall that he wanted to 
test *something* here for Mailman's purposes, so it's up to 
him to figure out what he really wants -- testing that the 
platform has a feeble time_t ain't it).

Logged In: YES 
user_id=12800

I'm inclined to remove the whole test.  Certainly testing
for OverflowError isn't useful (and if I ever thought it
was, I can't remember why), so about the only useful thing I
can think to test would be that a localtime() to mktime()
roundtrip is idempotent.

If we really wanted to test for OverflowError (or ValueError
as the docs specify /could/ occur instead), then would using
(sys.maxint,)*9 be better?  That still seems icky to me.

Logged In: YES 
user_id=21627

Removing the test sounds good to me; feel free to close this
report afterwards.

Logged In: YES 
user_id=12800

Done.