getmtime differs between Py2.5 and Py2.4

[Josef Dalcolmo]

I tried this on Windows only:

In Python 2.4 os.path.getmtim e returned the local time,
in Python 2.5 it seems to return GMT:

import os, time
print ctime.time(os.p ath.getmtime(fo o))

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

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Re: getmtime differs between Py2.5 and Py2.4

Is this a bug?

Why don't you read the responses posted earlier? John Machin
replied (in <1178232636.415 630.106320@l77g 2000hsb.googleg roups.com>)
that you are mistaken: There is NO difference between the outcome
of os.path.getmtim e between Py2.5 and Py2.4. It always did return
UTC, and always will.

Regards,
Martin

[Irmen de Jong]

Re: getmtime differs between Py2.5 and Py2.4

Martin v. Löwis wrote:

>Is this a bug?

>
Why don't you read the responses posted earlier? John Machin
replied (in <1178232636.415 630.106320@l77g 2000hsb.googleg roups.com>)
that you are mistaken: There is NO difference between the outcome
of os.path.getmtim e 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\*.p y

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\pyt hon.exe -c "import os; print os.path.getmtim e('p64.py')"
1164470381

[E:\Projects]c:\Python25\pyt hon.exe -c "import os; print os.path.getmtim e('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]

Re: getmtime differs between Py2.5 and Py2.4

On May 8, 3:26 am, Josef Dalcolmo <dalco...@vh-s.dewrote:

I tried this on Windows only:
>
In Python 2.4 os.path.getmtim e returned the local time,
in Python 2.5 it seems to return GMT:
>
import os, time
print ctime.time(os.p ath.getmtime(fo o))

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\pyth on -c "import os, time, sys;
print sys
..version, time.ctime(floa t(os.path.getmt ime('C:\\junk\
\newfile.txt')) )"

C:\junk>\python 24\python -c "import os, time, sys; print sys.version,
time.ctime
(float(os.path. getmtime('C:\\j unk\\newfile.tx t')))"
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>\python 25\python -c "import os, time, sys; print sys.version,
time.ctime
(float(os.path. getmtime('C:\\j unk\\newfile.tx t')))"
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]

Re: getmtime differs between Py2.5 and Py2.4

On May 8, 9:15 am, Irmen de Jong <irmen.NOS...@x s4all.nlwrote:

Martin v. Löwis wrote:

Is this a bug?

>

Why don't you read the responses posted earlier? John Machin
replied (in <1178232636.415 630.106...@l77g 2000hsb.googleg roups.com>)
that you are mistaken: There is NO difference between the outcome
of os.path.getmtim e 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\*.p y
>
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\pyt hon.exe -c "import os; print os.path.getmtim e('p64.py')"
1164470381
>
[E:\Projects]c:\Python25\pyt hon.exe -c "import os; print os.path.getmtim e('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]

Re: getmtime differs between Py2.5 and Py2.4

John Machin <sjmachin@lexic on.netwrote:

[E:\Projects]c:\Python24\pyt hon.exe -c "import os; print

os.path.getmtim e('p64.py')"

1164470381

[E:\Projects]c:\Python25\pyt hon.exe -c "import os; print

os.path.getmtim e('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.7200000286 102

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]

Re: getmtime differs between Py2.5 and Py2.4

On May 8, 1:04 pm, a...@mac.com (Alex Martelli) wrote:

John Machin <sjmac...@lexic on.netwrote:

[E:\Projects]c:\Python24\pyt hon.exe -c "import os; print

>
os.path.getmtim e('p64.py')" 1164470381
>

[E:\Projects]c:\Python25\pyt hon.exe -c "import os; print

>
os.path.getmtim e('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.2 8 - 1164470381

>
-3599.7200000286 102
>
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.
>

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]

Re: getmtime differs between Py2.5 and Py2.4

On May 7, 4:15 pm, Irmen de Jong <irmen.NOS...@x s4all.nlwrote:

Martin v. Löwis wrote:

Is this a bug?

>

Why don't you read the responses posted earlier? John Machin
replied (in <1178232636.415 630.106...@l77g 2000hsb.googleg roups.com>)
that you are mistaken: There is NO difference between the outcome
of os.path.getmtim e 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\*.p y
>
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\pyt hon.exe -c "import os; print os.path.getmtim e('p64.py')"
1164470381
>
[E:\Projects]c:\Python25\pyt hon.exe -c "import os; print os.path.getmtim e('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]

Re: getmtime differs between Py2.5 and Py2.4

On May 8, 10:15 am, "Martin v. Löwis" <mar...@v.loewi s.dewrote:

that you are mistaken: There is NO difference between the outcome
of os.path.getmtim e 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/tr...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.p ath.getmtime('t emp.txt'))"
Thu Feb 08 10:08:44 2007

C:\>c:\python25 \python -c "import os;import time;print
time.ctime(os.p ath.getmtime('t emp.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.p ath.getmtime('t emp2.txt'))"
Tue May 08 16:59:22 2007

C:\>c:\python25 \python -c "import os;import time;print
time.ctime(os.p ath.getmtime('t emp2.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_ATTR IBUTE_DATA lpFileInformati on;
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_mtim e ) );

/* Python 2.5+ */
GetFileAttribut esEx(argv[1], GetFileExInfoSt andard,
&lpFileInformat ion);
FileTimeToSyste mTime(&lpFileIn formation.ftLas tWriteTime, &stUTC);
printf("Time modified : %02d/%02d/%d %02d:%02d:%02d UTC\n",
stUTC.wMonth, stUTC.wDay, stUTC.wYear,
stUTC.wHour, stUTC.wMinute, stUTC.wSecond);
SystemTimeToTzS pecificLocalTim e(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 );
}

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Re: getmtime differs between Py2.5 and Py2.4

This is python 2.4.4 and Python 2.5.1 on windows XP.

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.getmt ime(r"c:\temp\t est_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.getmt ime(r"c:\temp\t est_os.diff")

1175704875.1825 342

Is your file system FAT, by any chance?

Regards,
Martin

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Re: getmtime differs between Py2.5 and Py2.4

>that you are mistaken: There is NO difference between the outcome

>of os.path.getmtim e between Py2.5 and Py2.4. It always did return
>UTC, and always will.

>
Different results are indeed obtained, as others have demonstrated
(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

[=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=]

Re: getmtime differs between Py2.5 and Py2.4

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.

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]

Re: getmtime differs between Py2.5 and Py2.4

Martin v. Löwis wrote:

>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.

>
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

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]

Re: getmtime differs between Py2.5 and Py2.4

Leo Kislov wrote:

>
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]

Re: getmtime differs between Py2.5 and Py2.4

Hi Martin,

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"" <martin@v.loewi s.dewrote in message
news:46401FDC.4 010705@v.loewis .de...

>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.

>
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