>> 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 error that the time stamps it reports may be off by an hour. This error is offset by the fact that your rendering through localtime() gives result different by one hour also, giving you the impression that Python 2.4 returns the correct result. > Now let's see what Python 2.5.1 says > > Creation Time: 01/02/2003 11:34:56 > Last Access Time: 01/02/2003 11:34:56 > Last Write Time: 01/02/2003 11:34:56 > > All times are off by 1 hour! The rendered times, yes. They are still correct - they are just off by 1 hour, because your rendering algorithm is different from the one that dir uses. It was 11:34 at the time when the file was created, as there was no daylight-saving time in effect in January 2003. According to your current time zone (which does have daylight-saving time), it was 12:34 when the file was created. > h: joe .txt 0 1/02/03 12:34 \ > > The text editor is reporting the correct timestamps too. Define "correct". According to your current time zone, or taking into account that the DST offset was different when the file was created? > Python 2.4.2 ALWAYS got it correct. Unfortunately, it didn't. That was one of the reasons to change it. > So unless you are saying that Windows is wrong, Python 2.5.1 has to be wrong > since it does not compare to what Windows reports. Windows isn't wrong. It just uses a different algorithm to render historical time stamps. Neither approach is right or wrong: - if you use the current time zone, you display a time-stamp that wasn't the reading of the wall clock when the action happened - if you adjust for DST changes, you get ambiguous time stamps, as "2:30 am" may denote two different points in time on the day when daylight saving time returns to normal time. The one true way to render time stamps is in UTC/GMT/Zulu time :-) > Even if it turns out that Windows has a bug and is wrong I still think that > Python should be reporting the same thing because what Windows reports is > what is expected. If Python reports something different (even if it was > correct) the information is not useful if it differs from what everything > else is reporting. For the cases where there is a 1h difference, Python reports *exactly* what Windows reports. Python 2.4 didn't. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
