Python 2.5.1 broken os.stat module

[Terry Reedy]

"Joe Salmeri" <JoeSalmeri at hotmail.com> wrote in message 
news:NYWdnUCXk6mPUv_bnZ2dnUVZ_jKdnZ2d at comcast.com...
| ""Martin v. Löwis"" <martin at v.loewis.de> wrote in message
| news:4662750b$0$29898$9b622d9e at news.freenet.de...
| >> 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 automatically adjust for DST (this is the default in
| >> Windows).
| >
| > 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 zone.

Joe, read the last sentence again.  Most of your reply shows that you have 
missed this basic point.

A 'time zone', as far as the math (and Windows) is concerned, *IS* an 
offset from GMT.    The shift from 'standard' to 'daylight' time is a 
one-hour change in the offset.  That has the same effect as moving to the 
standard time zone one hour to the east.  So Eastern Daylight Time is the 
same as Atlantic Standard Time (or whatever Canadians call the next zone 
for their maritime provinces).  Similarly, 'Central Daylight Time' is an 
alias for 'Eastern Standard Time'.  CDT and EST both translate to -5 (I 
believe) in Windows timezone lookup dictionary.  Because there are multiple 
names and abbreviations for most or all timezones, Windows has to 
separately keep track of which one the user expects to see.

[In my opinion, the Congressional mandate that we pretend to live somewhere 
to the east for over half the year is as arrogant and stupid as would be a 
mandate that we use 'adjusted Fahrenheit' (F - 10 degrees) during the 
summer so that temperatures 'seemed' lower. ;-]

| > When you explicitly change the time zone of your computer, you will
| > notice that all file time stamps immediately change also.

What Martin meant, of course, is the presented text representation thereof.

| 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.
|
| I understand that the actual UTC time value for the file has *not* 
changed.
|
| That local textual representation of the modification timestamp is what
| people and programs look at and work with and is what is displayed by the
| dir command and what Explorer displays.

And without a timezone attached, that 'local representation' is as 
ambiguous as any measurement without units.  Is 45 hot or cool?

| Changing the timezone will defintely change the "textual representation" 
of
| all timestamps just as you say (even though the actual UTC value has 
*not*
| changed), however, when DST starts/ends the "textual representation" of 
the
| timestamps on some files WILL ALSO CHANGE when the automatically adjust 
for
| DST setting is turned on.

To repeat, turning DST on *IS* a timezone change.  So you are talking about 
the *same* thing.

| In the following comments I am referring to the textual representation of
| the timestamp that the user is working with (I understand that the 
interal
| UTC timestamp for the file has *not* changed).
|
| The issue occurs when the timestamp for the file is in a period when DST 
was
| not in effect and DST is in effect for the current time OR when the
| timestamp for the file is in a period when DST was in effect and DST is 
not
| in effect for the current time.

Because the timezones change.  Geographically, UTC+X is the area where the 
relevant authorities mandate that clocks be set to offset X from UTC.  When 
the clocks jump, those areas jump!  In the US, at least, the UTC-6 area, 
for instance, jumps from where it was to what was previously the UTC-7 
area.  This spring, when there were different jump dates around the world, 
the overall configuration of zones (which areas had the same time) changed. 
Yes, a mess

| While it is true that I did change the timezone in the first part of the
| test (to establish the baseline), in the second part of the tests where 
the
| difference you are referring to occured, the timezone was *not* changed, 
the
| only thng that occured was that DST started.

Which *is* a timezone change.

| In that test the file had a timestamp of 01/01/2007 07:00 PM as shown by 
the
| dir command results.

As Martin said, that is not a timestamp.  It is an information-stripped 
representation thereof.

| When the date progressed to a point after DST had started Windows now
| reports the timestamp on that *unmodified* file now is 01/01/2007 08:00 
PM.

Because Windows changed the timezone offset by one hour.  Again, not a 
timestamp but an alternate info-deleted representation thereof.

| I did not change the timezone, the only thing that occurred was DST 
started.

Which *is* a timezone change.

| The internal UTC timestamp did NOT change, the issue is in Windows 
textual
| representation of that UTC timestamp to my local timezone and DST values,
| Windows now reports that the modification timestamp on the file as 1 hour
| later (again the actual UTC timestamp did *not* change).

It is Windows' fault that it deletes the time scale indication.  If there 
were a 'Congressional Stupidty' temperature scale (F-10) and Windows 
silently changed the scale for reporting historical temperature stamps 
(perhaps of max CPU temp each your, auto recorded on machines with such 
measurements), it would 'report' that such had changed, even thought they 
had not.

| > That's because the user is misinterpreting the data that Windows
| > reports. Windows isn't saying the file changed, Windows says that
| > the timezone changed.
|
| You mixed up my tests, in that case as shown above the timezone did *not*
| change, the only thing that changed was that DST started and the file was
| created during a time when DST was not in effect.

Need I repeat ;-?

Terry Jan Reedy