Article ID: 188891
Article Last Modified on 12/1/2000
APPLIES TO
- Microsoft FrontPage 98 Standard Edition
This article was previously published under Q188891
SYMPTOMS
After Daylight Saving Time takes effect, the "Modified By" value in FrontPage Explorer is changed to reflect an inaccurate recording of the "Modified Time".
CAUSE
This problem results when the server extensions recognize that the server's relationship to Greenwich Mean Time (GMT) has changed. This triggers a parse of all files in the Web to check for any date-related FrontPage components. This parsing is registered by the operating system as a modification of the file, even if no data in the file has changed.
RESOLUTION
To resolve this problem, install the latest version of the FrontPage 98 Server Extensions.
STATUS
Microsoft has confirmed this to be a problem in Microsoft FrontPage 98 for Windows. This problem was fixed with the 3.0.2.1706 version of the FrontPage Server Extensions.
MORE INFORMATION
This issue affects only Windows NT-based Web servers where Web content is located on an NTFS partition. In this situation, following a change from Standard Time to Daylight Saving Time (or vice versa), an incorrect Modified Time is displayed in the FrontPage Explorer, and the Modified By information is no longer available.
The exclusive source of this information for the FrontPage Explorer is the HTML file within the Vti_Cnf directory, specifically, the default Vti_Timecreated, Vti_Cacheddtm, and Vti_Timelastmodified values contained in this file.
The problem arises because the time zone for Western Europe (including Stockholm, Berlin, Rome, Bern, Brussels, and Vienna) changes to Daylight Saving Time (DST) on March 31, whereas the United States changes to Daylight Saving Time on April 5. Because the internal date calculations for time offsets are based on the April 5 switch to DST, files created by FrontPage between the local time zones' adoption of Daylight Saving Time and April 5 may show a modified time in FrontPage Explorer as one hour ahead of the current time.
The server is saving timestamps adjusted for Daylight Saving Time, but with the standard non-adjusted GMT offset. This means that the timestamps are actually not GMT-based. When FrontPage Explorer shows times in its views, it adjusts them to match its time zone settings, which is essentially done by converting to GMT and back again.
(This table is for client and server both in Central European Time)
------------------------------------------------------------------
Daylight? CET (GMT+1) GMT Timestamp FP Explorer shows
------------------------------------------------------------
Pre-adjust 13:00 12:00 13:00 + 0100 13:00
Post-adjust 14:00 12:00 14:00 + 0100 15:00
FrontPage Explorer shows 15:00 because looking at 14:00+0100 as a GMT would indicate that the file was saved at 13:00 GMT instead of 12:00. Then the client puts it back into its own local time zone, which is GMT+0100 plus another hour for Daylight Saving Time.
The end result is (13 + 1 + 1) = 15:00.
The Web is recalculated because, to the extensions, the time adjustment on the server represents a more recent edit than the last time the file(s) were edited by FrontPage. This recalculation is to account for the possibility that the user may not have used FrontPage to edit one of the HTML files. Because FrontPage has no information regarding who performed the most recent edit (it was the operating system that changed the date stamp), the Modified By value is discarded.
This behavior did not occur in FrontPage 97 because FrontPage 97 recorded times in the local time zone of the server. This was fine as long as the client and server were both using the same operating system and in the same time zone; however, problems arose whenever the time zones or operating systems of the two sides of the network interaction were not identical.
For more information about how Windows NT handles Daylight Saving Time, please see the following article in the Microsoft Knowledge Base:
129574 Time Stamp Changes with Daylight Savings
Keywords: kbbug kbfix KB188891
