[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review

[Larry Hastings]

On 02/15/2012 08:12 PM, Guido van Rossum wrote:
> On Wed, Feb 15, 2012 at 7:28 PM, Larry Hastings<larry at hastings.org>  wrote:
>> I fixed this in trunk last September
>> (issue 12904); os.utime now preserves all the precision that Python
>> currently conveys.
> So, essentially you fixed this particular issue without having to do
> anything as drastic as the proposed PEP...

I wouldn't say that.  The underlying representation is still 
nanoseconds, and Python only preserves roughly hundred-nanosecond 
precision.  My patch only ensures that reading and writing atime/mtime 
looks consistent to Python programs using the os module.  Any code that 
examined the nanosecond-precise values from stat()--written in Python or 
any other language--would notice the values didn't match.

I'm definitely +1 for extending Python to represent nanosecond precision 
ctime/atime/mtime, but doing so in a way that permits seamlessly adding 
more precision down the road when the Linux kernel hackers get bored 
again and add femtosecond resolution.  (And then presumably attosecond 
resolution four years later.)  I haven't read 410 yet so I have no 
opinion on it.

I wrote a patch last year that adds new Decimal ctime/mtime/atime fields 
to the output of stat, but it's a horrific performance regression 
(os.stat is 10x slower) and the reviewers were ambivalent so I've let it 
rot.  Anyway I now agree that we should improve the precision of 
datetime objects and use those instead of Decimal.  (But not 
timedeltas--ctime/mtime/atime are absolute times, not deltas.)


/arry