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 vstinner
Recipients Alexander.Belopolsky, Arfrever, belopolsky, jcea, khenriksson, larry, lars.gustaebel, loewis, mark.dickinson, nadeem.vawda, r.david.murray, rosslagerwall, skrah, vstinner
Date 2011-09-11.23:56:08
SpamBayes Score 3.476259e-06
Marked as misclassified No
Message-id <1315785369.77.0.698740163881.issue11457@psf.upfronthosting.co.za>
In-reply-to
Content
> 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?
History
Date User Action Args
2011-09-11 23:56:10vstinnersetrecipients: + vstinner, loewis, jcea, mark.dickinson, belopolsky, lars.gustaebel, larry, nadeem.vawda, Arfrever, r.david.murray, skrah, Alexander.Belopolsky, rosslagerwall, khenriksson
2011-09-11 23:56:09vstinnersetmessageid: <1315785369.77.0.698740163881.issue11457@psf.upfronthosting.co.za>
2011-09-11 23:56:09vstinnerlinkissue11457 messages
2011-09-11 23:56:08vstinnercreate