classification
Title: Change os.utimensat() and os.futimens() to use float for atime & mtime
Type: behavior Stage:
Components: Extension Modules Versions: Python 3.3
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: larry, rosslagerwall
Priority: normal Keywords:

Created on 2011-09-05 15:40 by larry, last changed 2011-09-05 19:12 by larry. This issue is now closed.

Messages (3)
msg143529 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2011-09-05 15:40
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.
msg143540 - (view) Author: Ross Lagerwall (rosslagerwall) (Python committer) Date: 2011-09-05 16:08
See #11457 for a long discussion about the API and whether to use decimal or not to get the full precision.
msg143555 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2011-09-05 19:12
I'm withdrawing this, as I've found a better way to approach the problem.
History
Date User Action Args
2011-09-05 19:12:47larrysetstatus: open -> closed
resolution: rejected
messages: + msg143555
2011-09-05 16:08:05rosslagerwallsetnosy: + rosslagerwall
messages: + msg143540
2011-09-05 15:40:39larrycreate