Foxpert Software Development & Consulting

Menu

Whitepapers
Downloads
Knowlbits
Guineu

2009-04Apr-02

ON SAVE DAYLIGHT RECOMPILE

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.

So this week is the week of the great recompile! If you build your project for the first time this week, you might notice that Visual FoxPro recompiles most files even if you haven't checked the "Recompile all" checkbox and haven't touched them in years. Participation in the great recompile depends on your storage location, though.

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.

Previous KnowlBits

RSS

February 2011 (2)

December 2010 (1)

October 2009 (2)

September 2009 (1)

August 2009 (4)

July 2009 (2)

June 2009 (2)

May 2009 (1)

April 2009 (1)

March 2009 (1)

August 2008 (1)

July 2008 (2)

May 2008 (1)

April 2008 (2)

January 2008 (2)

December 2007 (2)

November 2007 (2)

October 2007 (1)

September 2007 (1)

August 2007 (5)

July 2007 (4)

May 2007 (6)

March 2007 (3)

February 2007 (7)

January 2007 (6)

November 2006 (1)

October 2006 (3)

September 2006 (10)

June 2006 (2)

May 2006 (6)

April 2006 (1)


Impressum Kontakt Contact