> But that perspective is not directly relevant to *your* topic line. When
> you make a claim that os.stat is 'broken' and bugged, you are making a
> claim about the *programmer* experience -- in particular, experiencing a
> discrepancy between performance and reasonable expectation based on the
>
"Joe Salmeri" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|I have tried (unsuccessfully) to get you to view things from the end user
| perspective.
But that perspective is not directly relevant to *your* topic line. When
you make a claim that os.stat is 'broken' and bugged, you
I have tried (unsuccessfully) to get you to view things from the end user
perspective.
I wish that you would consider looking at what the end user sees because
that is what really matters.
Without end users we would not need to develop software would we?
This entire conversation was VERY nicel
Joe Salmeri schrieb:
> There is a conflict with the answers that you and Terry have given.
No, there isn't. See some of my earlier replies: both windows and python
are correct, despite the fact they give different results.
When Windows renders a time stamp, it always uses the current UTC
offset.
Perspective is often the source of problems with communication.
You view timezones and DST as offsets from GMT. I understand and respect
that perspective.
When I think of timezones and DST I think of the timezone setting and the
DST setting in Windows.
These settings are two separate settings
There is a conflict with the answers that you and Terry have given.
The original issue I raised was that I Python 2.5.1 and Windows did not have
the same textual represenation for a localize date.
You have stood true to the statements that Python 2.5.1 is correct and that
previous versions were
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> It appears that you may have missed part of my tests. Sorry it was such
>> a
>> long reply but I was trying to provide a lot of detail so that others had
>> a
>> clear understanding of what was going on.
>
> Ple
> Please understand that it is *extremely* tedious to follow your
> messages. It would have been much better if they had been short and
> to the point.
Sometimes it seems that it is impossible to please people.
When messages are short then people complain that they did not get
sufficient details
> | > You are misinterpreting what you are seeing. Windows is not claiming
> | > that the modification time changes when DST starts. Instead, it is
> | > claiming that the *same* time now has a *different* textual
> | > representation, because the computer now has moved to a different
> | > time z
> It appears that you may have missed part of my tests. Sorry it was such a
> long reply but I was trying to provide a lot of detail so that others had a
> clear understanding of what was going on.
Please understand that it is *extremely* tedious to follow your
messages. It would have been much
"Joe Salmeri" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| ""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
| news:[EMAIL PROTECTED]
| >> The short explaination of this issue is that the timestamp shown when
| >> you do a dir on a file that is on an NTFS volume changes by
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> The short explaination of this issue is that the timestamp shown when
>> you do a dir on a file that is on an NTFS volume changes by an hour
>> when DST starts and also when DST ends, even though the file has NOT
>>
> The short explaination of this issue is that the timestamp shown when
> you do a dir on a file that is on an NTFS volume changes by an hour
> when DST starts and also when DST ends, even though the file has NOT
> been modified!!! Note that this only happens if you have the setting
> turned on to
> It's not clear whether it's an error, however, localtime() does
> something different from what dir does.
Hi Martin,
First off thank you for spending your time to investigate this bug with me.
Thanks for pointing out the issue with Windows XP caching the access
timestamps,
I was not aware of
> File Name : P:\sw\Python\Lib\cgi.pyc
>
> python_access_ts: 05/31/2007 07:17 PM
> win_access_ts : 05/31/2007 06:35 PM
>
> File Name : P:\sw\Python\Lib\code.pyc
>
> python_access_ts: 05/30/2007 07:59 PM
> win_access_ts : 05/30/2007 07:22 PM
I have analyzed these cases in mor
>> How did you do that?
>
> I used a "touch" utility to set the dates but let's try it a different way.
What touch utility specifically? Is source code available of that tool?
> Looks like Python 2.4.2 is reporting the timestamps correctly
Unfortunately, no. Python 2.4 (and earlier) has an erro
> Reviewing my code it seems that it should still work with the 2.5.1 os.stat
> changes however that does not appear to be the case.
>
> Timestamps reported by os.stat() are no longer correct and the results are
> not even consistent.
I don't think this is the case. The results Python reports a
Hi Terry,
> If, when discussion is concluded here, you still think there is a bug,
> file
> a report on SF. Make a concise summary in the comments section and attach
> a file with the output from your experiments. You may have to submit the
> attachment separately after first submitting the rep
"Joe Salmeri" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| I hope I have provided enough information for you to reproduce the bug so
| that a solution can be found.
If, when discussion is concluded here, you still think there is a bug, file
a report on SF. Make a concise summa
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> I created a file and specifically set the created date, last accessed
>> date
>> and last write date to
>>
>> 01/02/2003 12:34:56
>
> How did you do that?
I used a "touch" utility to set the dates but let's tr
> I created a file and specifically set the created date, last accessed date
> and last write date to
>
> 01/02/2003 12:34:56
How did you do that?
> In the case of my above test I know exactly what the timestamp on the file
> is because I manually set it so that all 3 timestamps are the sa
Hi Tony,
I still believe there is a problem.
I was searching for os.stat problems so I hadn't seen that one yet. (THANKS)
I just read that thread but it seems that the conclusion was that this was a
bug in a Microsoft c runtime library.
Here's why I think there is still a problem:
I created a
On Jun 1, 9:16 am, "Joe Salmeri" <[EMAIL PROTECTED]> wrote:
> I just upgraded from Python 2.4.2 to Python 2.5.1 and have found some
> unexpected behavior that appears to be a bug in the os.stat module.
Have you read this thread?
http://groups.google.com/group/comp.lang.python/browse_thread/thread
I just upgraded from Python 2.4.2 to Python 2.5.1 and have found some
unexpected behavior that appears to be a bug in the os.stat module.
My OS is Windows XP SP2 + all updates.
I have several programs that have worked flawlessly on all previous Python
versions for years and they are now produc
24 matches
Mail list logo
