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