Python 2.5.1 broken os.stat module

["Martin v. Löwis"]

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