Synchronize directories time zone issue

[pol098]

Searched for this but found nothing relevant ("synchronize directories time zone"). Not sure if it's a MS Windows or TCMD issue. On doing a synchronize / synchronise / sync /synch directories, files are flagged as different which have the same name, size, minutes and seconds, but a different hour in the timestamp, obviously due to Windows's time zone handling or the like. Is there a way to prevent these files being listed (i.e., they should be treated as being the same unless they differ by more than 24 (or 12?) hours)? I think this should be automatic behaviour, possibly toggled by a configuration switch, not a filter that has to be set up.

The "Ignore date" in synchronize directories achieves this aim, but I think an option to restrict it only to differences which can be due to timezone issues (+- <24 hrs, same hour & minute) would 99.999...% remove the possibility of missing changed files with the same size.

Thanks

[J.A. Gruys]

Configuration | Options | Operation | NTFS daylight saving correction | x Ignore 1 hour daytime delay

[pol098]

Configuration | Options | Operation | NTFS daylight saving correction | x Ignore 1 hour daytime delay

Thanks, but I've always had that ticked. However, with files from all over the place in practice I often have differences of several hours. Example: I have an installation CD with a directory on it with files identical to those downloaded from the supplier's website. The difference is clearly a timezone matter, not identical files created at different times, as timestamps invariable differ by exactly 7:00:00 hours.


CCMD.CMD 3 15/07/09 06:31:42 15/07/09 13:31:42 3 CCMD.CMD
README.txt 138 01/03/10 12:31:08 01/03/10 19:31:08 138 README.txt
Setup.exe 193664 11/03/11 02:55:06 11/03/11 09:55:06 193664 Setup.exe
DATA\
1028.msi 2125824 11/03/11 02:50:36 11/03/11 09:50:36 2125824 1028.msi
1031.msi 2128384 11/03/11 02:51:24 11/03/11 09:51:24 2128384 1031.msi
1033.msi 2127360 11/03/11 02:52:06 11/03/11 09:52:06 2127360 1033.msi
1036.msi 2130432 11/03/11 02:52:38 11/03/11 09:52:38 2130432 1036.msi
1041.msi 2128384 11/03/11 02:53:14 11/03/11 09:53:14 2128384 1041.msi
2052.msi 2124800 11/03/11 02:54:14 11/03/11 09:54:14 2124800 2052.msi
PCDIA.CAB 35738523 11/03/11 02:55:48 11/03/11 09:55:48 35738523 PCDIA.CAB

[pol098]

Returning after a long time to this issue and the question I asked, I've understood how it happens, but that's not a solution (it would be useful if TCMD could allow ignoring a time difference of an exact number of hours up to 24). On NTFS file systems files are stored with UTC (GMT) internally, but display the modification time in the local timezone (which changes between summer and wintertime). But the FAT32 system doesn't support this, and stores the local time as the file modification time. This is not too bad if the file stays in the same time zone; at worst a 1 hour time difference can occur when some files are on NTFS, others on FAT (and TCMD can be set to ignore this). But when files are transferred between time zones and file systems, there can be many hours' time difference.

This apparently does sometimes happen in real life, I discovered. For example, files received from another timezone, stored on NTFS and at some time transferred to FAT32 and back again, will end up timestamped with a different time, reflecting the zone difference. The same files transferred again using NTFS only will have times differing by hours. I may have the details wrong, but the combination of timezone change and file system transfer has to be the explanation.