I want your feedback on the preference option (below) for dealing with the problem.
Do the explanations make sense?
Does the proposed choice of 60, 30, and 15 minute resolution cover all possible cases?
The proposed default is 60 minutes, and I think it best that this option be turned on by default. (The risk with it being turned on is that it is conceivable that an image might be flagged as “previously downloaded” when in fact it was not — comparisons are made by modification date/time, file size, and file name.)
The terminology to be used (e.g. “resolution”) is a bit tricky. To a native English speaker a term like “resolution” might make perfect sense, but what about non-native speakers, especially including those for whom their English is not great? Is there a better term that makes sense to both native and non-native English speakers?
I believe the traditional term is “offset”. I have no idea about what words may be used in other languages.
The text does not say anywhere what will be done if the option is checked, or if it is not checked. For sure, the wording will need to be crafted carefully, and what wording is best may depend on what you propose to do.
The time stamp in an individual image file on the SD card isn’t going to change, so I assume that the issue you are concerned about occurs when the current time in the camera is changed.
To be very picky, cameras record times according to whatever time the user has entered into the camera. Of course, most users would enter their local time, but someone who travels a lot might choose to use UTC to avoid issues, and some other users might not worry about clock drift and have absolute garbage times in their files.
I just reviewed a couple of Fujifilm camera manuals, and there is a provision for setting a travel time zone, but the delta is between the travel time zone and the home time zone. No reference to UTC. Quite a strange approach, but it is what it is.
You have to be able to handle both “spring forward” and “fall back”, so you have to apply the offset in both directions,
Time correction (minutes).
If I understand correctly, is it necessary to adapt the program to the exif time of the files?
Sorry english (google translate)
This is a great point. This shows why it’s a problem to design a UI like this on a Friday evening
On further reflection I’ll likely remove both paragraphs of explanation, and start very simply with “When detecting if a file has been previously downloaded:”
Instead of the explanations, I’ll instead link to the documentation on the website. Most people will never read it, but that’s okay as long as the functionality works!
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
Camera writes file. FAT32 timestamp is recorded in local time only, with zero knowledge of time zones.
As it scans the memory card or camera, Rapid Photo Downloader needs to take extra steps to interpret the time stamps so they actually make sense to a human, because time zones do matter to us in a pragmatic sense. All the details are in the code, e.g. here. These details are confusing so I won’t go into detail here, but they are important.
Time zone changes because of travel or daylight savings is starts / ends. All times on the file card are off by change in offset. There is no record of this on FAT32 file system.
That would appear to simultaneously make checking equality of timestamps easy and make interpreting the timestamps murder.
If I’m reading the code correctly, and mtime here:
is the unaltered last modified time from the file system, then checking equality should be easy and reliable.
For display purposes, the user definitely has to play along to the extent of religiously updating the current local time in their camera on each transition between standard and daylight time and on each travel event to a different time zone.
Plus, the dates of transitions between standard and daylight time are not the same in all locales.
It’s easy to test, assuming your local time is not UTC. Take a photo, attach the memory card or camera (mobile phones are different), and examine the mtime of the photo. The result will likely differ from what most people expect.
