OK - I admit I am confused. There is something clearly something funky about how Windows handles timezones and file timestamps, as is well explained in Beating the Daylight Savings Time bug and getting correct file modification times.

Beyond this there are some differences in behavior between different CVS clients. Between the original CVS, the enhanced CVSNT, and the built-in Eclipse CVS client there are … differences. Reading about the [cvsnt] CVS Time Zone Bug did not exactly help. Tested with Eclipse 3.0 rc2, CVSNT 2.0.41a, and CVS 1.11.17.

Beware: Cygwin “ls” returns different file times than the Windows “dir” command - so it is not just the CVS clients that are confused! The times reported by Windows are listed here. Did not try the Cygwin port of “cvs”. File times were recorded when the current time was DST.

Picking an older file with a non-DST file timestamp:

file timestamp CVS/Entries ============== ============== 12-21-02 17:55 12-22-02 00:55 (Eclipse checkout anytime) 12-21-02 17:55 12-22-02 00:55 (CVSNT checkout anytime) 12-21-02 17:55 12-22-02 00:55 (CVS checkout when not DST) 12-21-02 16:55 12-21-02 23:55 (CVS checkout when DST)

Picking a newer file with a DST timestamp:

file timestamp CVS/Entries ============== ============== 05-05-04 09:22 05-05-04 16:22 (Eclipse checkout anytime) 05-05-04 09:22 05-05-04 16:22 (CVSNT checkout anytime) 05-05-04 10:22 05-05-04 16:22 (CVS checkout when not DST) 05-05-04 09:22 05-05-04 15:22 (CVS checkout when DST)

Looks like CVSNT and Eclipse are consistent with each other and across a DST change. The original CVS is not consistent across DST changes.

Now the question is if I can somehow make ActiveCVS somehow account for these differences.

… think I am going to punt for now…