Thanks for the feedback Larry; yeah that patch definitely wasn't intended to be "production quality" -- more of a proof of concept.  I agree with your points, they'll be factored into the next patch.

However, I'm absolutely baffled by the Solaris 10 failure.  The more I looked into it, the weirder it got.  The issue is always the same:

    self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime"))
AssertionError: 1347752941.275297 != 1347752941.275296

That is, test_utime() always results in a st1.st_mtime that is "off-by-1" from st0.st_mtime.  The precision is well within the nanasecond resolution offered by utimensat, so it doesn't appear to be the same issue experienced by other platforms.

I'll have to break into the debugger again and see what's going on.

Side note: I noticed this comment/code just above _test_utime():

    def test_utime_dir(self):
        delta = 1000000
        st = os.stat(support.TESTFN)
        # round to int, because some systems may support sub-second
        # time stamps in stat, but not in utime.
        os.utime(support.TESTFN, (st.st_atime, int(st.st_mtime-delta)))
        st2 = os.stat(support.TESTFN)
        self.assertEqual(st2.st_mtime, int(st.st_mtime-delta))

That... seems to (albeit vaguely) describe what's going on here with Solaris 10.  I also noticed support.TESTFN is actually a directory in this test case.  Again, I'm not sure how that fits in with test_utime_dir() versus a second invocation of _test_utime(support.TESTFN) from test_utime().

test_utime_dir() is ultra-lax, test_utime() is ultra-strict, I'm not sure which one should be updated to match the other.