Hi Bob,
Thanks for your post.
My understanding on this issue is that there is an issue between quark and
files stored in Windows 2000 file shares revolving around time stamping of
the files. You manage an IT Data Center with a marketing group that has
gigabytes of quark files. Every spring/fall, this issue causes them much
pain in that they have to be irritated by quark telling them that the file
has been modified. If I have misunderstood your concern, please feel free
to let me know.
In Windows NT4, Quark Software reports this to be a known issue.
http://www.quark.com/service/desktop/support/techinfo/technotes.jsp?idx=96
I have searched in our database and found that the cause is that Quark
does
not appear to be utilizing the UTC time/date encoding schema. Problem
appears to be with Quark and that they keep the date/time of the file in
the embedding data string rather than the UTC time. This is why Quark has
the problem with Daylight Savings Time.
Based on my research, Quark's latest version is reported to no longer have
the time issue when Daylight Savings Time occurs.
Additional Information for your reference:
File times do not changed by Windows at the time of Daylight Savings Time
as stated by Quark Software.
Imagine changing every file stamp on every file on a SAN array in less
than
10 seconds, then changing it back. Not likely we are going to change the
time stamp on hundreds of thousands of files... twice in a matter of
seconds.
There is an MSDN article that states how dates are stored and interpreted
by Windows.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/bas
e/file_times.asp
A file time is a 64-bit value that represents the number of 100-nanosecond
intervals that have elapsed since 12:00 A.M. January 1, 1601 (UTC). The
system records file times whenever applications create, access, and write
to files. FAT records file times in local time. NTFS records file times
natively in FILETIME format, so they are not affected by changes in time
zone or daylight saving time.
Not all file systems can record creation and last access times and not all
file systems record them in the same manner. For example, on FAT, create
time has a resolution of 10 milliseconds, write time has a resolution of 2
seconds, and access time has a resolution of 1 day (really, the access
date). NTFS delays updates to the last access time for a file by up to one
hour after the last access.
Additionally, the Microsoft Knowledge Base article:
http://support.microsoft.com/?id=158588 states:
When Windows NT automatically adjusts for Daylight Savings Time, the
time/date stamp on files on NTFS volumes and the events in the event logs
appear to be shifted by one hour, even though the files and event records
were last created/changed prior to the Daylight Savings Time adjustment.
This behavior occurs because of the way that Windows NT stores time/date
stamp information. All time/dates displayed in Event Log events and files
on NTFS partitions are computed as offsets to UTC (which is the same as
Greenwich Mean Time [GMT]). When you select your time-zone from the
Control
Panel Date/Time applet, you are setting the value for UTC. The appropriate
number of hours are then added or subtracted to/from the stored UTC value.
This adjusted time is then displayed in any operation which reports local
time (that is, NT Explorer [NT 4.0], File Manager, directory listings, and
so on). When "Automatically Adjust for Daylight Savings Time" is selected,
an additional hour is added to GMT during Daylight Savings Time (the first
Sunday in April through the last Sunday in October).
Hope that helps and thanks for your understanding.
Thanks & Regards
Amanda Wang [MSFT]
Microsoft Online Partner Support
Get Secure! -
www.microsoft.com/security
====================================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================================
