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 larry
Date 2011-09-05.15:40:38
SpamBayes Score 5.7092286e-08
Marked as misclassified No
Message-id <1315237240.05.0.971546244676.issue12899@psf.upfronthosting.co.za>
In-reply-to
Content
The new functions os.futimens() and os.utimensat() update the timestamps of a file with nanosecond precision.  However, both functions take atime and mtime as a tuple: (seconds since epoch, nanoseconds).  Contrast this with os.utime(), which produces atime and mtime as a floating point number of seconds since epoch.

Why the mismatch between the APIs?  It simply forces the user to do the conversion themselves.  You can see this in the regression tests for these two functions--there's a lot of multiplying by 1e9 going on.

The only justification I can contrive is that the conversion of (secs+(1e-9*nsecs)) can be inaccurate; a double would need roughly one more byte of mantissa to be able to accurately preserve all possible nanosecond values.  But that ship has sailed--os.utime() produces inaccurate results, and afaik there's no other way to do it in the Python library.

os.futimens() and os.utimensat() should take atime and mtime in the floating-point format as produced by os.utime().

I'm happy to contribute the patch.
History
Date User Action Args
2011-09-05 15:40:40larrysetrecipients: + larry
2011-09-05 15:40:40larrysetmessageid: <1315237240.05.0.971546244676.issue12899@psf.upfronthosting.co.za>
2011-09-05 15:40:39larrylinkissue12899 messages
2011-09-05 15:40:38larrycreate