[Python-Dev] Proposing an alternative to PEP 410
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