New submission from Larry Hastings <la...@hastings.org>: 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. ---------- components: Extension Modules messages: 143529 nosy: larry priority: normal severity: normal status: open title: Change os.utimensat() and os.futimens() to use float for atime & mtime type: behavior versions: Python 3.3 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12899> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
