This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author trent
Recipients Arfrever, larry, pitrou, skrah, trent
Date 2012-10-19.13:18:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20121019131704.GD96081@snakebite.org>
In-reply-to <1350452794.13.0.0143785340066.issue15745@psf.upfronthosting.co.za>
Content
On Tue, Oct 16, 2012 at 10:46:34PM -0700, Trent Nelson wrote:
> 
> Trent Nelson added the comment:
> 
> 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've concluded that the problem on Solaris is actually unrelated
    to the original failures on FreeBSD and NetBSD that this issue
    was raised for (where os.stat() returns nanosecond resolution but
    os.utime() only accepts microsecond).

    I've raised a separate bug for this issue: #16287.
History
Date User Action Args
2012-10-19 13:18:08trentsetrecipients: + trent, pitrou, larry, Arfrever, skrah
2012-10-19 13:18:08trentlinkissue15745 messages
2012-10-19 13:18:08trentcreate