Martin v. Löwis <mar...@v.loewis.de> added the comment: > This predates both the inclusion of Decimal in Python (2.4) and > nanosecond resolution in the utime API (2008). I could find no > discussion of the change, so I don't know what other representations > were considered. It's hard to say what the author of the code might > have done if Decimal had existed back then, or if he foresaw > nanosecond resolution. > > However, that author is already present in this thread ;-) Martin?
I think I specifically expected that nanosecond resolution in the file system API will not be relevant ever, since a nanosecond is damned short. I also specifically wanted to support units of 100ns, since that is what NTFS used at that time (and still uses). I also considered that introducing float would cause backwards incompatibilities, and provided the stat.float_times setting, and made only the indexed fields return ints, whereas the named fields contained floats. I think I would have chosen an arbitrary-precision fractional type had one been available. 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 !!!). 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. If sub-nanosecond time stamps ever become a reality, st_[cma]time_asec fields could be added, for attosecond resolution. ---------- _______________________________________ 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
