>>>Every time after Daylight Savings Time changes the first project build results in every form in the system (over 300) re-compiling.
>>>Anyone know how to prevent this? It's a time waster and it also changes the date on every SCX and FRX. I have a utility to give me the true last modified date but..
>>>The date and time on my PC and on the Server are correct.
>>
>>
>>John, I think you could determine the cause by a simple test. Set the date to a point before the time change, and save some "fake change" to a form, like going into some code, pressing space, then backspace to remove the added space, then Ctrl+W. Exit VFP. Copy the .SCX and .SCT to some location. Change the date to a point after the time change, and then go in and do the same. Press Ctrl+W. Exit VFP. And copy over the .SCX and .SCT to the same location, but with a different name. Then use a utility like WinMerge to see what's changed internally.
>>
>>You'll likely find that somewhere in one of the binary memo fields there is an encoding indicating meta data about the date. You can find out exactly which bytes, and what changes, and then track those down to their actual location in the file.
>>
>>I'm guessing VFP is doing some date comparison based on that meta data, and due to some cross-DST bug, is seeing the form's date incorrectly and recompiles it.
>
>As I'd mentioned earlier, it appears to be linked to how OS reports timestamps in local time -- on filesystems using Universal Time internally, the same offset value is used for *all* timestamps when converting them to local time. For example, in Pacific timezone, local time is reported as being 8 hours behind Universal Time during standard time and 7 hours during daylight. So on the NTFS partitions, I tend to see timestamps "jumping" back and forth after the transition times from standard into daylight and from daylight into standard.


I would suspect a bug in Visual FoxPro, one which in converting the system time to timezone specific local time, not honoring the flag in both times which are different when the time changes, but rather using the condition of one of the flags (which indicates if the daylight savings time portion is used, or the non-daylight savings time portion is used), and is doing some kind of general memcmp() on the that for both times, and because one of them is not populated, it's doing the recompile, which then updates the time so that they are again synchronized for the next comparison.

Using:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724421%28v=vs.85%29.aspx

To obtain:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724949%28v=vs.85%29.aspx

typedef struct _TIME_ZONE_INFORMATION {
    LONG       Bias;
    WCHAR      StandardName[32];
    SYSTEMTIME StandardDate;
    LONG       StandardBias;
    WCHAR      DaylightName[32];
    SYSTEMTIME DaylightDate;
    LONG       DaylightBias;
} TIME_ZONE_INFORMATION, *PTIME_ZONE_INFORMATION;

And then using the return value from one of the GetTimeZoneInformation() to determine which one to use, and not considering both. I could be wrong though.