Daylight Savings Time (DST) causes exactly 1 hour difference on FAT

[MM-John]

When comparing to a USB flash drive in FAT or exFAT formats the time is reported as exactly 1 hour different on Windows because of time interpretation and Daylight Savings Time (DST). There's no workaround. If you manually change all the times on the USB drive then next DST change it appears wrong again. You'd need to change all the times on all your files in FAT twice a year.

Similar to the "Ignore time differences less than 3 seconds" option, can there be a "Ignore time differences of exactly 1 hour".

However, it's complicated, because it's probably 1hour+/-3 seconds. Ie both options combined together. Not totally sure of this.

For reference, the Eastern Standard Time (EST) changes to Eastern Daylight Time (EDT) in the summer in the USA (northern hemisphere).

Here is a similar discussion in a tool with similar comparison needs - FastCopy - for reference:

"Daylight Saving Time DST" problem (= "1 hour exact difference" problem) https://groups.google.com/g/fastcopy-bb-eng/c/0ovpgsRc66E/m/ItX7q7-yAQAJ

Is the DST problem fixed in FastCopy v. 3.40? https://groups.google.com/g/fastcopy-bb-eng/c/IAitTRfFojY/m/woRXcWvgCAAJ

[PenGoFly]

+1 this would be awesome. I have image files from my Android that differ by an hour and some seconds from the backed up files.

[auge8472]

Please keep in mind, that a hardcoded difference of one hour can fail in some cases. Currently there is only one region with a different time zone shift. It's Lord Howe Island with a shift of 30 minutes. On the other hand there are a few changes to regulation in several countries and regions on this planet every year. No one can say, if countries will sometime change to another shift or will introduce an additionally double summer time (+2 hours).

It would be better, if the program would be able to identify a datetime as standard time or daylight saving time/summer time by the timestamp of a file itself. This could also fail because of files, that was saved in region A but the comparision is made in region B. But this is IMHO an edge case.

Maybe the program has to ave a switch to activate or deactivate the time shift feature in a comparision. To do it, the program must have access to a up-to-date list of time zones. On unixoid OS'ses there is such a list available. I don't know, if this is the case on Windows.

With a data medium, that has time zone support for the file dates, this would be a no-problem.

[PenGoFly]

It definitely needs to be an option that can be switched on if needed only. Like the "ignore time difference less than 3 seconds" option that is needed for write time in FAT filesystems.

I would appreciate an option "ignore time difference of one hour" (and heck, why not 30 minutes) to accomodate for DST differences.

Unfortunately I don't think this can be automated as every system keeps it's time differently internally. E.g. most Linux store time as GMT and show it to the user in their local timezone including DST. Windows tends to work the other way around. But both can be configured to behave differently, nowadays.

And even more true, we are not able to predict what DST changes will be possible in the future.

[MM-John]

Thinking about this, is it more accurate to say there are three states that can result from a file comparison:

1. Same
2. Different
3. Trivially different (or some such)

Would it be possible for the tool to always detect differences of less than 3 seconds, and any perhaps exact increments of 1 hour (give or take 3 seconds) and report these differently, visually in the compare window? Maybe even exactly 30 min (give or take 3 sec) also?

For example, if the tool powers up with these 'ignore' settings default off, then, still the compare result might be able to use a different color for files that differ from these very suspicious times only--and have the same size.

Or place an icon next to the times of such files, or perhaps only highlight the times not the whole line, or maybe just the time and not the date, or perhaps just the digits of the time that differ (or something) .

It seems like such differences are a fairly clearly delineable, distinct state.

By the way, this feature, no matter what variant, has the possibility of missing some truly modified file (marking it as unmodified under these ignore settings).

Doing some math, the odds or your next edit to a file falling within a 3 second window of the hour or your previous edit is I believe 3/3600 = 1/1200. And if you're editing your file 10 times a day at random times (but who edits at random times in real life), so that you have 10 chances to hit that window: 1 - (1 - 1/1200)^10 = 1% a little bit less, if my math is correct.

Similarly, if you're editing the same file 10x per day for 365 days then you would hit it an average of 3 times per year = 356 10 1/1200, again, if my math is correct.

However, before we get too excited, the edit would have to result in a file of the exact same lenght length