homepage

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

AltStyle によって変換されたページ (->オリジナル) /