STINNER Victor <victor.stin...@haypocalc.com> added the comment: > If a two-ints representation > is considered necessary, I'd favor a rational number (numerator, > denominator) over a pair (second, subsecond); this would also support > 2**-32 fractions (as used in NTP !!!).
Which OS uses NTP timestamps in stat()? Or are you thinking about other functions? > As yet another approach, I propose a set of st_[cma]time_nsec fields > which always give an int representing the integral part of the time > stamp in nanoseconds since the epoch. As I wrote before, I would prefer to keep the same number of fields in the Python structure and in the C structure, but I don't have a strong opinion on this choice. If we want to stay close the C API, we can use a namedtuple: s = os.stat(filename, time_struct=True) ctime = s.ctime.tv_sec + ctime + s.ctime.tv_nsec * 1-e9 Or maybe: s = os.stat(filename, time_struct=True) ctime = s.ctime.sec + ctime + s.ctime.nsec * 1-e9 A namedtuple is not a good idea if we want to support other time resolutions, because some developer may write "s.ctime[0] + ctime + s.ctime[1]" without taking care of the time resolution. Because Windows uses a resolution of 100 ns and POSIX uses 1 ns, I still don't see why we should support something else. If we use the following API, we can still add other resolutions later (using a new argument): s = os.stat(filename, nanoseconds=True) sec, nsec = s.ctime ctime = sec + nsec * 1e-9 What should be done if the OS only has a resolution of 1 sec? Raise an exception, or use nsec=0? Same question if we add *_nsec fields: these fields are optional, or always present? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11457> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
