RetroSearch Browse

Fri Feb 24 00:47:05 CET 2012 · https://mail.python.org/pipermail/python-dev/2012-February/116781.html

On 02/23/2012 02:35 PM, Victor Stinner wrote:
> I rejected datetime.datetime because I want to get nanosecond
> resolution for time and os modules, not only for the os module. If we
> choose to only patch the os module (*stat() and *utime*() functions),
> datetime.datetime would be meaningful (e.g. it's easier to format
> datetime for an human, than a Epoch timestamp).

I think a piecemeal approach would be better.  I'm aware of a specific 
problem with os.stat / os.utime--the loss of precision problem that's 
already been endlessly discussed.  Is there a similar problem with these 
other functions?

> I don't
> think that there is a need to support datetime+int or datetime-float,
> there is already the timedelta type which is well defined.

I suggest this because I myself have written (admittedly sloppy) code 
that assumed it could perform simple addition with st_mtime.  Instead of 
finding out the current timestamp and writing that out properly, I 
occasionally read in the file's mtime, add a small integer (or even 
smaller float), and write it back out.

> For os.stat(), you should use the UTC timezone, not a naive datetime.

Why is that more appropriate?  IIUC, timestamps ignore leap seconds and 
strictly represent "seconds since the epoch".  In order to correctly 
return a time in the UTC time zone we'd have to adjust for leap 
seconds.  Naive datetimes bask in their happy ignorance of such 
complexities.

//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120223/315d8943/attachment.html>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2012-February/116781.html below:

[Python-Dev] Proposing an alternative to PEP 410