Python 2.5.1 broken os.stat module

["Martin v. Löwis"]

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. That is the only way to guarantee that a time stamp uniquely
identifies points in time: i.e. two files with the same time stamp
where also modified at the same time.

OTOH, Python's localtime function tries to apply the UTC offset that
was likely in force at the time indicated by the time stamp. I say
likely, because it probably doesn't know exactly when DST started in
what year (I might be wrong - Python defers to some Microsoft API
to perform the conversion). While this apparently better matches what
you expect, it also is ambiguous: two files authored at 2:15 a.m.
might still be an hour apart, if that is on the day when DST switches
to standard time.

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

Yes - but not because localtime reported the wrong value, but because
stat() didn't report UTC times.

> I agree with you that Python 2.5.1 is correct which means that Windows is 
> showing the incorrect dates.

And yet, I claim they are both correct - just different.

> Since that point in time you and Terry have disagreed with my statements 
> regarding timezones and DST.

I don't see how. Terry claims the Windows result is correct, and so do I.

> From that date up until just before DST starts both Windows AND Python 2.5.1 
> will report that date as 01/02/2007 07:00 PM.

EST, that is.

> Once DST starts Python 2.5.1 will still report that date as 01/02/2007 07:00 
> PM, however Windows will now report that
> date as 01/02/2007 at 08:00 PM.

EDT.

01/02/2007 7:00 PM EST == 01/02/2007 8:00 PM EDT

So they print indeed the same output, even though the text is different.

> I agree and believe that Python 2.5.1 is reporting the correct textual 
> representation of that timestamp, however, using
> *your* logic that a DST change *is a timezone change* that would mean that 
> Python 2.5.1 is wrong and should be reporting the
> date 1 hour later just as Windows is reporting.

No. Python prints the stamp according to the time zone that was in force
when the file was created. Of course, it can't be sure (since the
computer may have lived in an entirely different time zone at the
time), but it assumes that the computer has not moved, and it assumes
to know when DST started in 2007 (which it probably does know correctly;
I wouldn't be so sure about 1981).

> You cannot have it both ways.

Sure can.

> If a DST change is the same as a timezone change then Python 2.5.1 should be 
> reporting the dates that Windows reports.

You are misunderstanding what localtime() does.

> If a DST change is NOT the same as a timezone change then Python 2.5.1 
> should be reporting the dates that it currently is.

You are misunderstanding that Windows does *not* use localtime(),
but windows_localtime(). Both consider the current timezone, but in
a different way.

Regards,
Martin