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, ericography, jcea, khenriksson, larry, lars.gustaebel, loewis, mark.dickinson, nadeem.vawda, r.david.murray, rhettinger, rosslagerwall, skrah, vstinner
Date 2012-01-30.13:14:20
SpamBayes Score 4.5655307e-10
Marked as misclassified No
Message-id <CAMpsgwZvBkzAqNsBJLextiT2kPdZZ-fsFB1GrziEA7kQ_pX72g@mail.gmail.com>
In-reply-to <1327893719.5.0.977023684576.issue11457@psf.upfronthosting.co.za>
Content
> I think that one of available types of time values returned by os.stat() should allow to directly pass these values to os.futimens() and os.utimensat(), which expect (time_sec, time_nsec) tuples.

Oh, I realized that these two functions were added to Python 3.3, so
it is not too late to change their API. I would prefer to limit the
number of timestamp formats: Python 3.2 has float and datetime, I (and
Martin) propose to add Decimal to Python 3.3 (to get nanosecond
resolution). (sec, nsec) is a new format, except if Python 3.2 has
already functions expecting such tuple?

I know that the underlying C function expects a timespec structure,
but Python can try to use a higher level API, isn't it?

Decimal is more practical than a tuple because you can just write :
t2-t1 to compute a time delta. Decimal has other advantages (read the
issue for the full list ;-)).
History
Date User Action Args
2012-01-30 13:14:21vstinnersetrecipients: + vstinner, loewis, rhettinger, jcea, mark.dickinson, belopolsky, lars.gustaebel, larry, nadeem.vawda, Arfrever, r.david.murray, skrah, Alexander.Belopolsky, rosslagerwall, khenriksson, ericography
2012-01-30 13:14:20vstinnerlinkissue11457 messages
2012-01-30 13:14:20vstinnercreate