There were some also set to 2043 which is a valid datetime, albeit in the future, but they failed the same as the 1907 ones. Unfortunately Windows doesn't adhere to epoch time, I just edited the timestamps on a file - the minimum is 1st Jan 1601, so it needs to cope. Edit: January 1, 1601 NTFS, COBOL, Win32/Win64 1601 was the first year of the 400-year Gregorian calendarcycle at the time Windows NT was made.
I've spotted a bug relating to date modified on files. I was having an issue where the sync on the destination computer would never stop indexing the same files over and over. After a lot of head scratching I've noticed the date modified on the files in question were either in the future (2043) or in the past (1970) This is because they were taken from a digital cameras which didn't have the date/time set properly. The files sync'd over OK but they were set to 1970 on the destination computer or some other datetime that didn't match. The indexer got stuck in some kind of loop, maybe the files hashed ok but then something was failing with regards to the date? Anyway I fired up FreeFileSync which instantly picked up on this, copied and overwrote the files and now BTSync is happily sat there without the indexing problem. Here's one of the files affected... hope it helps someone out (and hope some devs fix it soon)