getmtime differs between Py2.5 and Py2.4
Josef Dalcolmo
I tried this on Windows only:
In Python 2.4 os.path.getmtime returned the local time,
in Python 2.5 it seems to return GMT:
import os, time
print ctime.time(os.path.getmtime(foo))
differs on Python 2.4 and Python 2.5 by the timezone.
Now, the implementation of the two stat calls differs on Windows
between the two versions.
I actually like the new behaviour better, because I believe the
reported time of a file should not depend on the timezone or other
local settings, however the old behaviour is the time also Windows
shows - and there is an incompatibility.
Is this a bug?
- Josef
"Martin v. Löwis"
Why don't you read the responses posted earlier? John Machin
replied (in <1178232636.4...@l77g2000hsb.googlegroups.com>)
that you are mistaken: There is NO difference between the outcome
of os.path.getmtime between Py2.5 and Py2.4. It always did return
UTC, and always will.
Regards,
Martin
Irmen de Jong
Err.....:
[E:\Projects]dir *.py
Volume in drive E is Data Serial number is 2C4F:9C2D
Directory of E:\Projects\*.py
31-03-2007 20:46 511 log.py
25-11-2006 16:59 390 p64.py
7-03-2007 23:07 207 sock.py
3-02-2007 16:15 436 threads.py
1.544 bytes in 4 files and 0 dirs 16.384 bytes allocated
287.555.584 bytes free
[E:\Projects]c:\Python24\python.exe -c "import os; print os.path.getmtime('p64.py')"
1164470381
[E:\Projects]c:\Python25\python.exe -c "import os; print os.path.getmtime('p64.py')"
1164466781.28
This is python 2.4.4 and Python 2.5.1 on windows XP.
The reported time clearly differs.
--Irmen
John Machin
> I tried this on Windows only:
>
> In Python 2.4 os.path.getmtime returned the local time,
> in Python 2.5 it seems to return GMT:
>
> import os, time
> print ctime.time(os.path.getmtime(foo))
I think you mean time.ctime :-)
>
> differs on Python 2.4 and Python 2.5 by the timezone.
>
You have presented no evidence. Did you read my reply to your previous
post?
> Is this a bug?
Is what a bug?
My timezone is *TEN* hours away from UTC. Here's what I get [Windows
XP Pro SP2]:
C:\junk>dir newfile.txt
Volume in drive C has no label.
Volume Serial Number is 7D12-D6D2
Directory of C:\junk
08/05/2007 09:17 AM 0 newfile.txt
1 File(s) 0 bytes
0 Dir(s) 44,508,061,696 bytes free
C:\junk>for %v in (4,5) do \python2%v\python -c "import os, time, sys;
print sys
.version, time.ctime(float(os.path.getmtime('C:\\junk\
\newfile.txt')))"
C:\junk>\python24\python -c "import os, time, sys; print sys.version,
time.ctime
(float(os.path.getmtime('C:\\junk\\newfile.txt')))"
2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] Tue May
08 09:17:
12 2007
C:\junk>\python25\python -c "import os, time, sys; print sys.version,
time.ctime
(float(os.path.getmtime('C:\\junk\\newfile.txt')))"
2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)]
Tue May 08
09:17:12 2007
C:\junk>
To avoid bandwidth waste, I've omitted similar results for Python 2.1,
2.2, and 2.3.
John Machin
> Martin v. Löwis wrote:
> >> Is this a bug?
>
> > Why don't you read the responses posted earlier? John Machin
> > that you are mistaken: There is NO difference between the outcome
> > of os.path.getmtime between Py2.5 and Py2.4. It always did return
> > UTC, and always will.
>
> > Regards,
> > Martin
>
> Err.....:
>
> [E:\Projects]dir *.py
>
> Volume in drive E is Data Serial number is 2C4F:9C2D
> Directory of E:\Projects\*.py
>
> 31-03-2007 20:46 511 log.py
> 25-11-2006 16:59 390 p64.py
> 7-03-2007 23:07 207 sock.py
> 3-02-2007 16:15 436 threads.py
> 1.544 bytes in 4 files and 0 dirs 16.384 bytes allocated
> 287.555.584 bytes free
>
> [E:\Projects]c:\Python24\python.exe -c "import os; print os.path.getmtime('p64.py')"
> 1164470381
>
> [E:\Projects]c:\Python25\python.exe -c "import os; print os.path.getmtime('p64.py')"
> 1164466781.28
>
> This is python 2.4.4 and Python 2.5.1 on windows XP.
> The reported time clearly differs.
>
> --Irmen
Well nitpicked, but irrelevant to the OP's perceptual problem.
The reported time clearly differs due to the result being (as
documented) now a float instead of an int. The OP is complaining about
an alleged difference of time-zone magnitude (i.e. at least 30
minutes, not 0.28 seconds). Somehow he has got the idea that Python
2.4 & earlier returned local time, not UTC.
HTH,
John
Alex Martelli
> > [E:\Projects]c:\Python24\python.exe -c "import os; print
os.path.getmtime('p64.py')"
> > 1164470381
> >
> > [E:\Projects]c:\Python25\python.exe -c "import os; print
os.path.getmtime('p64.py')"
> > 1164466781.28
> >
> > This is python 2.4.4 and Python 2.5.1 on windows XP.
> > The reported time clearly differs.
> >
> > --Irmen
>
> Well nitpicked, but irrelevant to the OP's perceptual problem.
>
> The reported time clearly differs due to the result being (as
> documented) now a float instead of an int. The OP is complaining about
> an alleged difference of time-zone magnitude (i.e. at least 30
> minutes, not 0.28 seconds). Somehow he has got the idea that Python
> 2.4 & earlier returned local time, not UTC.
Please look at those number again, beyond the float/int distinction.
>>> 1164466781.28 - 1164470381
-3599.7200000286102
the difference (rounding to an int number of seconds) is just about one
hour; in certain parts of the world (Europe and Africa), that could
indeed be a timezone issue.
Alex
John Machin
Whoops! I looked at the start & the end but not the middle [sorry,
Irmen].
OK, I suspect a daylight-saving issue. I'm at UTC-1000, with no DST in
effect.
I get only the int/float difference, not a 1 hour difference and not a
10 hour difference.
What we need now is for someone in northern America or Asia (2 or more
hours offset from UTC), with and without DST if effect, to try it out.
Leo Kislov
> Martin v. Löwis wrote:
> >> Is this a bug?
>
> > Why don't you read the responses posted earlier? John Machin
> > that you are mistaken: There is NO difference between the outcome
> > of os.path.getmtime between Py2.5 and Py2.4. It always did return
> > UTC, and always will.
>
> > Regards,
> > Martin
>
> Err.....:
>
> [E:\Projects]dir *.py
>
> Volume in drive E is Data Serial number is 2C4F:9C2D
> Directory of E:\Projects\*.py
>
> 31-03-2007 20:46 511 log.py
> 25-11-2006 16:59 390 p64.py
> 7-03-2007 23:07 207 sock.py
> 3-02-2007 16:15 436 threads.py
> 1.544 bytes in 4 files and 0 dirs 16.384 bytes allocated
> 287.555.584 bytes free
>
> [E:\Projects]c:\Python24\python.exe -c "import os; print os.path.getmtime('p64.py')"
> 1164470381
>
> [E:\Projects]c:\Python25\python.exe -c "import os; print os.path.getmtime('p64.py')"
> 1164466781.28
>
> This is python 2.4.4 and Python 2.5.1 on windows XP.
> The reported time clearly differs.
Let me guess: your E drive uses FAT filesystem?
-- Leo
Tony Meyer
> that you are mistaken: There is NO difference between the outcome
> of os.path.getmtime between Py2.5 and Py2.4. It always did return
> UTC, and always will.
In revision 42230, you checked in a change to posixmodule.c with the
following code comment:
/* The CRT of Windows has a number of flaws wrt. its stat()
implementation:
- time stamps are restricted to second resolution
- file modification times suffer from forth-and-back
conversions between
UTC and local time
Therefore, we implement our own stat, based on the Win32 API
directly.
*/
(See http://svn.python.org/view/python/trunk/Modules/posixmodule.c?rev=42230&view=log
)
Different results are indeed obtained, as others have demonstrated
(other than the irrelevant float/int distinction). The following C
sample program illustrates:
C:\>a d:\temp.txt
Time modified : Thu Feb 08 10:08:44 2007
Time modified : 02/07/2007 22:08:44 UTC
Time modified : 02/08/2007 11:08:44 Local
C:\>c:\python24\python -c "import os;import time;print
time.ctime(os.path.getmtime('temp.txt'))"
Thu Feb 08 10:08:44 2007
C:\>c:\python25\python -c "import os;import time;print
time.ctime(os.path.getmtime('temp.txt'))"
Thu Feb 08 11:08:44 2007
(My local time is UTC-12).
This doesn't happen with every file:
C:\>c:\python24\python -c "import os;import time;print
time.ctime(os.path.getmtime('temp2.txt'))"
Tue May 08 16:59:22 2007
C:\>c:\python25\python -c "import os;import time;print
time.ctime(os.path.getmtime('temp2.txt'))"
Tue May 08 16:59:22 2007
C:\>a d:\temp2.txt
Time modified : Tue May 08 16:59:22 2007
Time modified : 05/08/2007 04:59:22 UTC
Time modified : 05/08/2007 16:59:22 Local
A key fact here, I believe, is that in February (when temp.txt was
last modified), my local time was UTC-11. I expect this is the
suffering that your comment in posixmodule.c refers to (it looks to me
like Python 2.5 is correct).
Cheers,
Tony
---
#include <time.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <stdio.h>
#include <windows.h>
int main( int argc, char **argv )
{
WIN32_FILE_ATTRIBUTE_DATA lpFileInformation;
SYSTEMTIME stUTC, stLocal;
struct __stat64 buf;
int result;
/* Python 2.4 style */
result = _stat64( argv[1], &buf );
if( result != 0 )
perror( "Problem getting information" );
else
printf( "Time modified : %s", _ctime64( &buf.st_mtime ) );
/* Python 2.5+ */
GetFileAttributesEx(argv[1], GetFileExInfoStandard,
&lpFileInformation);
FileTimeToSystemTime(&lpFileInformation.ftLastWriteTime, &stUTC);
printf("Time modified : %02d/%02d/%d %02d:%02d:%02d UTC\n",
stUTC.wMonth, stUTC.wDay, stUTC.wYear,
stUTC.wHour, stUTC.wMinute, stUTC.wSecond);
SystemTimeToTzSpecificLocalTime(NULL, &stUTC, &stLocal);
printf("Time modified : %02d/%02d/%d %02d:%02d:%02d Local\n",
stLocal.wMonth, stLocal.wDay, stLocal.wYear,
stLocal.wHour, stLocal.wMinute, stLocal.wSecond);
}
"Martin v. Löwis"
> The reported time clearly differs.
Interesting. They don't for me:
C:\temp>dir test_os.diff
Volume in drive C has no label.
Volume Serial Number is 7414-6FC4
Directory of C:\temp
04.04.2007 18:41 3.661 test_os.diff
1 File(s) 3.661 bytes
0 Dir(s) 5.595.955.200 bytes free
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.path.getmtime(r"c:\temp\test_os.diff")
1175704875
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.path.getmtime(r"c:\temp\test_os.diff")
1175704875.1825342
Is your file system FAT, by any chance?
Regards,
Martin
"Martin v. Löwis"
>> of os.path.getmtime between Py2.5 and Py2.4. It always did return
>> UTC, and always will.
>
> (other than the irrelevant float/int distinction). The following C
> sample program illustrates:
Right. However, contrary to what the OP claimed, 2.4 does *not*
return local time - it still returns UTC. It may just return
"a different" UTC.
> A key fact here, I believe, is that in February (when temp.txt was
> last modified), my local time was UTC-11. I expect this is the
> suffering that your comment in posixmodule.c refers to (it looks to me
> like Python 2.5 is correct).
In case there was any doubt: your tests show that 2.4 does not
return local time. The output of dir matches the results of
the time.ctime output, that must meant that the ctime input
was UTC.
Now, that there is a one-hour difference is an inherent problem
with the FAT file system (so I assume you use FAT on your disk
drive). FAT has an inherent problem with UTC file stamps, as
the time stamps are stored in local time. So if you have an old
time, you can only interpret it in a meaningful way by assuming
that the machine was in the same time zone when the file was
created as it is now. The the DST issue come in: should one assume
that the DST switched since when the time stamp was created;
depending on what you assume here, a one-hour difference will
occur.
IIRC (and I clearly didn't at the beginning of the thread):
The MS CRT tries to adjust time stamps because of these problems,
but does so incorrectly. In particular, it adjusts time stamps
on NTFS volumes as well, which *are* in UTC. So even though
the system reports the correct time stamp, the CRT will
return the wrong one.
Python 2.5 fixes this, bypassing the CRT.
So yes: the time stamps returned in 2.4 and 2.5 may differ.
But still: they were always UTC, and always will be. It's
just that 2.4 had a bug which 2.5 has fixed.
Regards,
Martin
"Martin v. Löwis"
> hour; in certain parts of the world (Europe and Africa), that could
> indeed be a timezone issue.
With the help of Tony Meyer, we rediscovered the explanation: because
of a bug in the Microsoft C run-time library, the UTC time reported by
2.4 may have been off by one hour (it wasn't local time - just off
by one hour). This was due to DST issues. They have been fixed in 2.5,
which now reports the correct UTC value.
Regards,
Martin
Josef Dalcolmo
Well, indeed I got only a 1 hour difference, on my machine (local time
here is +1 hour). But when I temporarily set the local time of my
machine to GMT I the difference became 0, therefore I assumed wrongly it
had something to do with the local time difference.
Thanks to everyone helping to clarify this. My response was slow,
because I have been experiencing problems with my newsreader setup.
- Josef
Irmen de Jong
>
> Let me guess: your E drive uses FAT filesystem?
>
> -- Leo
>
Nope, its all NTFS on my system.
Anyway this doesn't matter, as the true cause is explained in another reply in this
thread (bug in c runtime library of Python 2.4).
--Irmen
Joe Salmeri
Please see my response to Tony Meyer titled "Python 2.5.1 broke os.stat
module"
I provide a sample program that demonstrates that the results that are
produced by the Python 2.4.2 os.stat module ALWAYS match the results that
Windows Explorer displays as well as the results of the dir /tc, dir /ta,
and dir /tw commands.
When you run that sample program using Python 2.5.1 the results that it
produces do NOT match what Windows returns. In my small sample test the
Python 2.5.1 os.stat results were wrong more than 50% of the time.
I can see that you guys have already spent alot of time investigating this
but surely the results should match what Windows Explorer says or what the
dir command returns???
Unless you are saying that a fully patched Windows XP SP2 + WindowsUpdates
system is using that broken Microsoft c runtime library which is causing
Explorer and cmd.exe to return incorrect results.
Even if that was the case, it would not explain how when I manually set the
3 timestamps for a file to 01/02/2003 12:34:56 that Windows and Python 2.4.2
display the correct date and time but Python 2.5.1 displays the wrong one.
Thanks for your assistance.
Joe
""Martin v. Löwis"" <mar...@v.loewis.de> wrote in message
news:46401FDC...@v.loewis.de...
Neil Hodgson
> I can see that you guys have already spent alot of time investigating this
> but surely the results should match what Windows Explorer says or what the
> dir command returns???
One problem I have seen is that Windows Explorer and its File
Properties sheet sometimes cache time values. Even closing and reopening
the properties can show the old value. dir should always read the times
though.
Neil
Joe Salmeri
>news:C2U7i.7432$wH4.2849@news-
>
> One problem I have seen is that Windows Explorer and its File
> Properties sheet sometimes cache time values. Even closing and reopening
> the properties can show the old value. dir should always read the times
> though.
I've seen that problem too but this is a NEW file so there shouldn't have
been anything to cache :-)
Plus after the timestamp is set then Explorer shows the new value and dir
and other tools all seem to be in sync with the time value displayed, with
the exception of python 2.5.1.
Joe