[Python-Dev] Proposing an alternative to PEP 410 (original) (raw)

Larry Hastings larry at hastings.org
Fri Feb 24 00:47:05 CET 2012

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>

More information about the Python-Dev mailing list