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 larry
Recipients Arfrever, larry
Date 2011-09-05.22:18:42
SpamBayes Score 0.00019646523
Marked as misclassified No
Message-id <1315261123.28.0.935761850011.issue12904@psf.upfronthosting.co.za>
In-reply-to
Content
> It's a duplicate of issue #11457.

No.  #11457 is a how-many-angels-on-the-head-of-a-pin discussion proposing new representations of ctime/mtime/atime to preserve nanosecond accuracy.  This patch changes the behavior of os.utime, os.futimes, os.lutimes, and os.futimesat so they conserve all of the existing representation's accuracy, making them consistent with os.stat.

> (Python >=3.3 has os.utimensat() and os.futimens().)

How is that relevant?

I mean, sure, I leveraged some of the work from that support in my patch--it's heavily reliant on the preprocessor macros HAVE_UTIMENSAT and HAVE_FUTIMENS now generated by configure.  (Thanks, Ross!)  But the presence of those functions does not mitigate the loss of accuracy inside os.utime &c.
History
Date User Action Args
2011-09-05 22:18:43larrysetrecipients: + larry, Arfrever
2011-09-05 22:18:43larrysetmessageid: <1315261123.28.0.935761850011.issue12904@psf.upfronthosting.co.za>
2011-09-05 22:18:42larrylinkissue12904 messages
2011-09-05 22:18:42larrycreate