> 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.