[New-bugs-announce] [issue11457] Expose nanosecond precision from system calls

[Kris Henriksson]

New submission from Kris Henriksson <kthenriksson at gmail.com>:

The most recent (issue 7) release of the POSIX standard mandates support for nanosecond precision in certain system calls. For example, the stat structure include a timespec struct for each of mtime, atime, and ctime that provides such nanosecond precision.[1] There is also an futimens call that allows setting the time accurate to the nanosecond.[2] Support for such precision is available at the least on 2.6 Linux kernels.

1. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html
2. http://pubs.opengroup.org/onlinepubs/9699919799/functions/futimens.html

Currently, the Python float type is used everywhere to express times in a single value (such as the result from os.stat). However, since this is implemented in CPython using type double (and possibly similarly elsewhere) it is impossible to obtain sufficient precision using a float.

Therefore, it would be useful to expose the number of seconds and nanoseconds separately
to allow full precision. Perhaps adding these values as additional members to the return value from os.stat would be most useful, something like .st_atimensec that Linux sometimes uses, or else just follow the POSIX standard to include a sub-struct.

This is important for example with the tarfile module with the pax tar format. The POSIX tar standard[3] mandates storing the mtime in the extended header (if it is not an integer) with as much precision as is available in the underlying file system, and likewise to restore this time properly upon extraction. Currently this is not possible.

3. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html

----------
components: Library (Lib)
messages: 130478
nosy: khenriksson
priority: normal
severity: normal
status: open
title: Expose nanosecond precision from system calls
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________