<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
On 02/23/2012 02:35 PM, Victor Stinner wrote:
<blockquote
cite="mid:CAMpsgwbpZhTC4P9nPth3iftH3OegAHdMq5xxb9fALmJeq2i4ow@mail.gmail.com"
type="cite">
<pre wrap="">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).</pre>
</blockquote>
<br>
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?<br>
<br>
<br>
<blockquote
cite="mid:CAMpsgwbpZhTC4P9nPth3iftH3OegAHdMq5xxb9fALmJeq2i4ow@mail.gmail.com"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:CAMpsgwbpZhTC4P9nPth3iftH3OegAHdMq5xxb9fALmJeq2i4ow@mail.gmail.com"
type="cite">
<pre wrap="">For os.stat(), you should use the UTC timezone, not a naive datetime.</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<i>/arry</i><br>
</body>
</html>