is anyone using FAT, changing timezones and syncing times?

I have just opened a (draft) PR to remove a longstanding workaround for
problems with Windows/FAT timekeeping.  Essentially, FAT is treated as
being in local time by Windows (rather than UTC as ~all other
filesystems), and this causes the times to change as the user's computer
changes timezone (DST, travel).  Thus, if syncing times, files appear to
have new times (actually they *do* have new times).  If it's a DST
change, or a number of other changes (Chicago to New York), that's 1
hour.  A number of other changes (Sydney to London) aren't 1 hour.

And, an intentional change of an hour in a non-FAT filesystem will be
missed:
  https://urldefense.com/v3/__https://github.com/bcpierce00/unison/issues/72__;!!IBzWLUs!S2QlsSVZMQGKPRnwpBmZH3gQvEKNiy6aMSroy4XdD2bqkzOWkFkpHyjK1VQs1ChkothV5FjI_voJSmqRdg$ 

Overall, my view is that it's more important to have correct behavior
than to guess to work around what I see as a design defect (changing the
TZ interpretation of FAT as the computer's timezone changes).

If you think something else is going on with FAT and timezones, please
feel free to comment in the PR.

If you are simultaneously using FAT, changing timezones by 1 hour, and
syncing times, you may want to contemplate if there are reasonable
workarounds that do not break semantics for UTC-based filesystems and
don't add a lot of complexity.

Also, trip reports for those using the workaround now would be
interesting.

https://urldefense.com/v3/__https://github.com/bcpierce00/unison/pull/1046__;!!IBzWLUs!S2QlsSVZMQGKPRnwpBmZH3gQvEKNiy6aMSroy4XdD2bqkzOWkFkpHyjK1VQs1ChkothV5FjI_vqIUKedFA$ 

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].