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 -- http://mail.python.org/mailman/listinfo/python-list