![]() Windows, on the other hand, seems to be automatically adding an hour to any DST file and seems to ignore the camera DST setting completely and.Telling the camera that you are in DST automatically moves the time forward on the file by one hour Both LR and Downloader Pro are reading the dates for renaming correctly and are matching what the camera recorded.My conclusions from this latest test are as follows: All of the FileModifyDate EXIF files had the correct times, but showed a -7:00 offset for all the files taken during DST regardless of whether the camera had DST on or off the offset for this field for non-DST dates was -8:00 (and DST was set to off in the camera).EXIFToolGUI showed the proper DST flags from the camera, and/but the timezone offsets were static (-8 for PST and PDT, -5 for EST and EDT).Windows File Explorer (and FastStone Image Viewer which must read the same data as File Explorer) universally moved all of the DST files ahead by 1 hour, but lesft the non-DST file times alone and,.LR Classic imported these files and shows the same file times.DownloaderPro renamed the files with these same times.The time stamps in the FileModifyDate EXIF field reflected the same times that the camera recorded in all of the copies of the test files.Here is what I learned from looking at the files in EXIFToolGUI and in Faststone Image Viewer (which previously displayed the same changes that Windows File Explorer did): I used Downloader to rename and move the files directly from the SD card, from copies of files downloaded to my PC, and I also renamed imported copies from LR directly from the SD card. I also decided to run some test files on a Nikon D750 with various dates (during DST both with and without DST checked in the camera settings in another time zone during DST with and without DST checked in the camera settings and in two different time zones outside of DST). ![]() Does anybody know if Windows pulls its date information from a different source other than the EXIF data? And does anybody know why a renaming and copying of the file would trigger this date adjustment, when the original file reads correctly? Just trying to better understand this issue if possible. I have reached out to the author of Downloader Pro, but have not yet received a response. But I cannot figure out what could be triggering the misread by some software and not others. I know that there are Windows issues that relate to DST and UTC as well as time issues that are handled differently in FAT32 and NTFS. But, when the date/time is displayed in Windows Explorer File Properties box, or in FastStone Image Viewer, it is exactly one hour ahead, despite the EXIF data showing the correct time. When Downloader Pro copies and renames a file that was taken during the months when we observe DST, the times in the EXIF data read correctly when the file is viewed in Jeffrey Friedl's Image Metadata Viewer or with EXIFTool GUI. I have been looking to use Breeze Systems Downloader Pro to do some file renaming and copying and found an interesting quirk that I am trying to better understand.
0 Comments
Leave a Reply. |