Apparently I glossed over a couple of things when replying on a Friday evening as well. 
There are at least two distinct issues:
- Correctly recognizing whether a file has already been downloaded.
- Presenting the date/time values in correct local time in the UI.
My primary concern would be the first issue.
I re-read the post by @swizzly. This part:
makes me wonder if the most likely explanation is one of these:
- their in-camera image numbering has wrapped, so for example the DSCF0123.raf on the SD card today is a different image than the DSCF0123.raf that was previously downloaded by RPD.
- they used some in-camera feature that altered the file.
- they made some changes to the file while the SD card was in the computer (or some other device).
I would not expect the camera to go and rewrite all the file modification timestamps on its SD card(s) if the current time setting in the camera was changed. So if the same SD card with some of the same files is presented to RPD multiple times, the file modification time for any file that is on the SD card more than one of those times should be unchanged, even if the current time setting in the camera is changed.
If RPD saves the file modification timestamp verbatim from the SD card file system, and compares the saved timestamp to the timestamp currently found on the SD card, then I honestly don’t see how the time zone used to set the time in either the camera or the computer matters (for comparison purposes). On the other hand, if some conversion is applied to the timestamp before RPD saves it, then there could be an exposure.
If there is an issue, you could check for a time discrepancy that is an exact multiple of 15 minutes and within the maximum time span between time zones ( +/- 26 hours – go figure!). There are a few time zones that are UTC + nn:45.
https://en.wikipedia.org/wiki/List_of_UTC_time_offsets