Unison has Windows-inspired workaround code to ignore time differences of an hour, leading to incorrect behavior

[hadmut]

Unison just caused me a lot of time for headache and debugging. I was synchronizing a heap of files (pics from digital camera), which had a wrong mtime due to time zone problem, i.e. they were wrong for about an hour. I've corrected these mtimes at one file system, but unison denied to synchronize.

I was analyzing the bug in the source repo just to find that it is (see NEWS or possible_deltas in props.ml) made intentionally to fix a problem with slow daylight saving time detection under Windows.

What a nasty trap.

Please make this configurable or use it only if Windows is involved.

[bcpierce00]

I wonder if the workaround is even needed any more -- it dates from a long time ago, and I imagine Windows may have gotten better about this issue in the meantime.

[hadmut]

Well, there's still DOS-Filesystems with a time granularity of 2 Seconds (only even seconds) out there, but I'd really recommend to put these possible deltas into a configuration variable and make unison precise by default.

BTW, under Linux it can be quite important to also set the fractions of a second (e.g. for Make). Unison should be able to synchronize times with full precision.

[bcpierce00]

Yes, I just meant the 1-hour hack.

I haven't looked at the relevant bits of the code in a while: does Unison not synchronize mtimes with full system precision? I agree that it should.

[alkuzad]

@hadmut propably this would do the job #51

[bcpierce00]

Yes, we should really generalize this and make it more configurable. Happy to accept a PR (though probably some further discussion about design would be good before diving into implementing, if someone wants to have a go at it).