ON SAVE DAYLIGHT RECOMPILE
2009-04Apr-02
This year I lost another hour of my life. I suffered the switch to daylight saving time twice: The first time early March in Seattle in the USA, the second time the past weekend in Germany. Windows has come a long way to adjust to these changes automatically, other devices I own aren't as smart, unfortunately. But that's a different story.
On NTFS, the standard file format for Windows these days, all file time stamps are stored in UTC time. UTC means Universal Time Coordinates and is a modern way of saying Greenwich Mean Time. That is, if people save their files all around the world within the same 100 nanoseconds, the time stamp for these files is identical. The time zone doesn't have any impact at all on the value that is stored.
Applications that determine time stamps usually do not work on the raw UTC time structure. Instead they rely on an operating system function to convert the UTC time stamp with its wierd format into a regular time structure based on the local system time. During your day to day work this behavior is what you expect.
Strange things happen, though, when you change the timezone offset, either by changing the timezone or by switching to or from daylight saving time. If you create a file at 9:00AM in January and look at it's creation time in April you'll see that it has been created at 10:00AM. The time that's 9:00 in the winter is 10:00 in the summer (spring forward, fall back).
The time stamp always reflects the absolute time, not the local time when you created a file. This allows Windows to precisely determine the time elapsed since the last modificiation. It also puts all files into creation order, even if you are a frequent traveller that changes time zones every day.
How does this relate to Visual FoxPro, after all?
Visual FoxPro optimizes the compile process and, by default, only compiles files that have been changed. A form or a class libary need to be recompiled when either the file itself has been edited, or when an associated included file has changed. The latter forces Visual FoxPro to keep track of when the include file has last changed.
While a sensible approach would have been to recompile whenever the include file is newer than the form or the class library, this is not the approach that FoxPro takes. Microsoft decided to use a more fail-proof way and includes the time stamp of all dependent header files in the VCX in a binary format. As you can guess this time is stored in the local time format.
So, twice a year the timezone offset changes and the include file suddenly has a different last modified date. Visual FoxPro, recognizing that the form isn't en par with the include file, decides to recompile the form.
Now you know why daylight saving time wastes hours of recompile time in Visual FoxPro projects all around the world... twice a year.
Applications that determine time stamps usually do not work on the raw UTC time structure. Instead they rely on an operating system function to convert the UTC time stamp with its wierd format into a regular time structure based on the local system time. During your day to day work this behavior is what you expect.
Strange things happen, though, when you change the timezone offset, either by changing the timezone or by switching to or from daylight saving time. If you create a file at 9:00AM in January and look at it's creation time in April you'll see that it has been created at 10:00AM. The time that's 9:00 in the winter is 10:00 in the summer (spring forward, fall back).
The time stamp always reflects the absolute time, not the local time when you created a file. This allows Windows to precisely determine the time elapsed since the last modificiation. It also puts all files into creation order, even if you are a frequent traveller that changes time zones every day.
How does this relate to Visual FoxPro, after all?
Visual FoxPro optimizes the compile process and, by default, only compiles files that have been changed. A form or a class libary need to be recompiled when either the file itself has been edited, or when an associated included file has changed. The latter forces Visual FoxPro to keep track of when the include file has last changed.
While a sensible approach would have been to recompile whenever the include file is newer than the form or the class library, this is not the approach that FoxPro takes. Microsoft decided to use a more fail-proof way and includes the time stamp of all dependent header files in the VCX in a binary format. As you can guess this time is stored in the local time format.
So, twice a year the timezone offset changes and the include file suddenly has a different last modified date. Visual FoxPro, recognizing that the form isn't en par with the include file, decides to recompile the form.
Now you know why daylight saving time wastes hours of recompile time in Visual FoxPro projects all around the world... twice a year.