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:04:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
Larry and I just chatted about this on IRC.  Summary:

 1.)  I was wrong about os.stat() affecting atime.  I fired up a
      console session on Solaris to "prove" my atime observation
      only to find os.stat() had no impact on atime:

        % ./python
        Python 2.7.3+ (2.7:90a46f8943d0, Oct 18 2012, 11:09:15) [C] on sunos5
        Type "help", "copyright", "credits" or "license" for more information.
        >>> import os
        >>> fname = 'configure'
        >>> st0 = os.stat(fname)
        >>> os.utime(fname, (st0.st_atime, st0.st_mtime))
        >>> st0.st_atime
        >>> st1 = os.stat(fname)
        >>> st1.st_atime

      So, we can ignore my "but os.stat() affects atime!" noise
      earlier in this report.

 2.)  Regardless of the underlying platform, the unit tests should
      test utime() with nano, micro and second resolution.  However,
      the tests should be cognizant of the underlying platform's
      os.stat() versus os.utime() resolution when testing the actual

      That is, if you pass a nanosecond time to os.utime() on a platform
      that doesn't have underlying nanosecond support for utime (i.e. no
      utimensat()), then expect a microsecond resolution time back from

 3.)  Regarding fixed times versus re-setting the first results of our
      stat() call: no strong opinion either way -- the main objective
      is to ensure the tests have good coverage and are robust.  So
      whatever gets the job done.
Date User Action Args
2012-10-19 13:04:32trentsetrecipients: + trent, pitrou, larry, Arfrever, skrah
2012-10-19 13:04:32trentlinkissue15745 messages
2012-10-19 13:04:32trentcreate