This fix will be included in the MacCVS Pro 2.5b3 release.

This weekend, the US will revert from Daylight Savings Time (DST) to standard time. This rather useless practice has irritated many millions whom to this day have no idea why we do this.

Amusingly enough, this can cause problems with both MacCVS Pro 2.2 and 2.5.

The HFS file system stores file modification dates in local time. So, if have a Mac set to Detroit, MI as your time zone (EST) and you modify a file at 2 PM on 10/27/1999, the file's modification date will still be shown as 2 PM even if you change your time zone to London, England or something else.

HFS Plus, on the other hand, stores modification dates in GMT and does the conversion "on the fly" to the particular time zone setting. So, with the time zone set to London, England, that same file would appear to be modified at 8 PM! (or whatever, I can't remember how many hours ahead Europe is...)

Since these two file systems store dates differently, after the DST change MacCVS, in certain cases, will mistakenly mark files as modified because the time stamp mismatches.

If you are using MacCVS 2.2 with HFS+, you will encounter this problem because MacCVS 2.2 stores modification dates in local time. Since the file modification dates will change on an HFS+ disk after the DST change, the modification dates will mismatch.

If you are using MacCVS 2.5, you will encounter this problem on a HFS file system because the application writes entry files with GMT time. (I have no choice, that is the spec) When MacCVS Pro 2.5 asks the OS how many hours the computer is off from GMT, the computer will answer with 1 hour less (or more) and the modification dates will mismatch.

An easy, temporary solution is to NOT use the Daylight Savings Time checkbox in the Date/Time control panel, but to just move your system clock an hour forward (or backward).

The long term solution has not been determined yet. Basically we have the option of ignoring the date mismatch if it is exactly one hour or check to see if the file lives on a HFS/HFS+ file system and act accordingly. Neither sounds very appealing.

Last but not least, MacCVS Pro is not the only one affected. As far as I know, both GNU MacCVS 3.1 and MacCVSClient 1.4.2 exhibit the same problem.

Final disclaimer: I have not tested any HFS+ situations because I don't have enough drive space, but what I said is definitely true for HFS.

Final final disclaimer: I wrote this on a nominal lack of sleep. Return to Main Page