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 Arfrever, belopolsky, jcea, khenriksson, lars.gustaebel, loewis, mark.dickinson, nadeem.vawda, r.david.murray, rosslagerwall, vstinner
Date 2011-06-24.19:55:37
SpamBayes Score 1.2906343e-13
Marked as misclassified No
Message-id <>
> I suggest that rather than using composite time stamps,
> decimal.Decimal is used to represent high-precision time in Python.

Hey, why nobody proposed datetime.datetime objects? Can't we improve the datetime precision to support nanoseconds? I would prefer to have a nice datetime object instead of a integer with an "unknown" reference (epoch). Or does it cost too much (cpu/memory) to create "temporary" datetime objects when the user just want to check for the file mode?

Well, the typical usecase of a file timestamp is to check if a file has been modified (mtime greater than the previous value), or if a file is newer than other one (mtimeA > mtimeB). I don't think that formating the timestamp is the most common usage of os.stat() & friends. float, int tuples and Decimal are all comparable types.

For timestamps arguments (e.g. signal.sigtimedwait, #12303), I would like to be able to pass a tuple (int, int) *or a float*. It is not because the function provides high precision that I need high precision. I bet that most user only need second resolution for signal.sigtimedwait for example.

If you want to pass Decimal: why not, as you want :-) But we have to write a shared function to parse timestamps with a nanosecond resolution (to always accept the same types).

By the way, Windows does also use timestamps with a nanosecond resolution, it's not specific to POSIX! Oh! And Python has a os.stat_float_times(False) function to change globally the behaviour of the stat functions! It remembers other bad ideas like the datetime.accept2dyear, sys.setfilesystemencoding() or sys.setdefaultencoding(). I don't like functions changing globally the behaviour of Python!
Date User Action Args
2011-06-24 19:55:38vstinnersetrecipients: + vstinner, loewis, jcea, mark.dickinson, belopolsky, lars.gustaebel, nadeem.vawda, Arfrever, r.david.murray, rosslagerwall, khenriksson
2011-06-24 19:55:38vstinnersetmessageid: <>
2011-06-24 19:55:37vstinnerlinkissue11457 messages
2011-06-24 19:55:37vstinnercreate