This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients Alexander.Belopolsky, Arfrever, belopolsky, jcea, khenriksson, larry, lars.gustaebel, loewis, mark.dickinson, nadeem.vawda, r.david.murray, rosslagerwall, skrah, vstinner
Date 2011-09-09.21:55:24
SpamBayes Score 8.5782564e-10
Marked as misclassified No
Message-id <>
In-reply-to <>
> 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.
Date User Action Args
2011-09-09 21:55:25loewissetrecipients: + loewis, jcea, mark.dickinson, belopolsky, lars.gustaebel, vstinner, larry, nadeem.vawda, Arfrever, r.david.murray, skrah, Alexander.Belopolsky, rosslagerwall, khenriksson
2011-09-09 21:55:24loewislinkissue11457 messages
2011-09-09 21:55:24loewiscreate