• Welcome to the Lightroom Queen Forums! We're a friendly bunch, so please feel free to register and join in the conversation. If you're not familiar with forums, you'll find step by step instructions on how to post your first thread under Help at the bottom of the page. You're also welcome to download our free Lightroom Quick Start eBooks and explore our other FAQ resources.
  • Dark mode now has a single preference for the whole site! It's a simple toggle switch in the bottom right-hand corner of any page. As it uses a cookie to store your preference, you may need to dismiss the cookie banner before you can see it. Any problems, please let us know!

File Renaming/Moving DST Time Quirk

Status
Not open for further replies.

Replytoken

Senior Member
Lightroom Guru
Premium Classic Member
Premium Cloud Member
Joined
Dec 7, 2007
Messages
3,066
Location
Puget Sound
Lightroom Experience
Intermediate
Lightroom Version
Classic
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. 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. 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.

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 I cannot figure out what could be triggering the misread by some software and not others. I have reached out to the author of Downloader Pro, but have not yet received a response. 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.

Thanks,

--Ken
 
Time recorded by the camera is always UTC. There is also a Local time field recorded as an offset to UTC. If your camera does or does not have a DST switch, this local time could be off by an hour.

So as an example, Let’s say the camera is set to the correct DST local time BUT the DST switch in the Camera settings is set to Standard time not DST, the local time will appear correct but it will be off by an hour at UCT.

Does this explain what you are seeing?
Look to the camera setting in the original file to see if UCT off set is correct for your time zone.


Sent from my iPad using Tapatalk
 
@Replytoken

I have run into this problem in different ways. At times, the backup battery in my D3 would get loose, but I didn't know about it before startng some photography, or "something" happens and I get dates in the year 2080 or 2099. My go to tool to fix such metadata issues is https://www.portablefreeware.com/?id=1450

I'm sure that there are other ways to solve this problem but this tool does the job for me.

I have found from experience that it is better to fix the EXIF outside of Lightroom Classic, if you are dealing with RAW files. Once you have fixed the EXIF data, there is no issue with import into LR Classic.

Phil Burton
 
Time recorded by the camera is always UTC. There is also a Local time field recorded as an offset to UTC. If your camera does or does not have a DST switch, this local time could be off by an hour.

So as an example, Let’s say the camera is set to the correct DST local time BUT the DST switch in the Camera settings is set to Standard time not DST, the local time will appear correct but it will be off by an hour at UCT.

Does this explain what you are seeing?
Look to the camera setting in the original file to see if UCT off set is correct for your time zone.


Sent from my iPad using Tapatalk
Hi Cletus,

Thanks for replying. I have compared two sample files in EXIFTool GUI against their modified files (one from my D500 and one from my Olympus E-M1 Mk I) and am copying the applicable EXIF lines below :

D500
FileModifyDate2018:06:30 10:02:42-07:002018:06:30 11:02:41-07:00
ModifyDate2018:06:30 11:02:412018:06:30 11:02:41
CreateDate2018:06:30 11:02:41.792018:06:30 11:02:41.79
Timezone-08:00-08:00
DaylightSavingsYesYes

E-M1
FileModifyDate2018:05:19 21:09:38-07:002018:05:19 22:09:38-07:00
DateTimeOriginal2018:05:19 22:09:382018:05:19 22:09:38
CreateDate2018:05:19 22:09:382018:05:19 22:09:38

It appears that the FileModify Date in both cameras has changed, but I am not certain why. Does the camera record the non-DST date and then apply the DST offset? In the case of the E-M1, I do not believe there is a DST setting, so this is a bit more confusing.

And to further complicate matters, the Created and Modified dates in the Windows File Properties box display the time one additional hour forward in the files that were copied and renamed (11:02:41 becomes 12:02:41), but Windows Photos displays the correct time (11:02:41).

--Ken
 
@Replytoken

I have run into this problem in different ways. At times, the backup battery in my D3 would get loose, but I didn't know about it before startng some photography, or "something" happens and I get dates in the year 2080 or 2099. My go to tool to fix such metadata issues is https://www.portablefreeware.com/?id=1450

I'm sure that there are other ways to solve this problem but this tool does the job for me.

I have found from experience that it is better to fix the EXIF outside of Lightroom Classic, if you are dealing with RAW files. Once you have fixed the EXIF data, there is no issue with import into LR Classic.

Phil Burton
I agree that date/time screw ups are best handled with EXIFTool GUI before the files enter LR, but that is not exactly the case here. The camera appears to have done what it was supposed to do, but there is a software glitch either in Downloader Pro or Windows 10 that is causing an error in displaying the correct time in files that were taken during DST. Yes, I could run them through EXIFTool GUI, but this is not really a one-off event. What I am trying to understand is which program has the glitch - Downloader Pro or Windows.

--Ken
 
I agree that date/time screw ups are best handled with EXIFTool GUI before the files enter LR, but that is not exactly the case here. The camera appears to have done what it was supposed to do, but there is a software glitch either in Downloader Pro or Windows 10 that is causing an error in displaying the correct time in files that were taken during DST. Yes, I could run them through EXIFTool GUI, but this is not really a one-off event. What I am trying to understand is which program has the glitch - Downloader Pro or Windows.

--Ken
I@replytoken

When you do hear back from Breeze Systems, I will be curious about the reply, One thing that stopped me from using Downloader Pro is that it ignores XMP files. Otherwise I would be using it a lot.

Phil Burton
 
I@replytoken

When you do hear back from Breeze Systems, I will be curious about the reply, One thing that stopped me from using Downloader Pro is that it ignores XMP files. Otherwise I would be using it a lot.

Phil Burton
Will do. As I am primarily using it on the front end for renaming and making backups, and as I do not use XMP files, that has not been an issue for me. But I am hoping the author, Chris, will hopefully provide some explanation or possible solution.

--Ken
 
FWIW, I have two updates to share. First, Chris, the author of Downloader Pro did provide me with two responses. I am copying his responses below:

It could be an issue with the EXIF data or the way Windows is reading the file timestamps. Downloader Pro reads the date and time from the DateTime fields in the EXIF data when naming the files.
and later
I've checked the code in Downloader Pro for setting the file creation and modification times and it is correct. The problem appears to be that the Windows libraries used to set the file status get confused if the status is set outside DST but the time being set is during DST. If you use the date time tokens to specify the download folder and/or filename it will use the correct time. It's only the file creation and modification times that Windows get wrong. You can disable this by unchecking "Use image capture time for file timestamp" which will result in the values being set to when the file was downloaded.

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). 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.

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):
  • 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;
  • DownloaderPro renamed the files with these same times;
  • LR Classic imported these files and shows the same file times;
  • 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,
  • 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);
  • 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)
My conclusions from this latest test are as follows:
  • Both LR and Downloader Pro are reading the dates for renaming correctly and are matching what the camera recorded. Telling the camera that you are in DST automatically moves the time forward on the file by one hour;
  • 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
  • EXIFTool GUI's FileModifyDate field seems to show a -7:00 offset to all files during DST even if the camera has DST set to off and it shows a -8:00 offset to all files recorded during a non-DST portions of the year
I also talked with Microsoft/Github engineer and his first response are that dates are generally a mess and there is not one standard that everybody uses other than to set everything to UTC with no offset. So, it appears that there are at least two attempts to provide useful data about time and DST by the camera companies (the DST flag used by some companies and the time zone/UTC offset setting). Unfortunately, it seems that Microsoft has decided to ignore most of this information and just automatically add an hour to its File Properties dialog box. I have not yet reconciled while my first sample above had a different FileModifyDate, but those samples were from different camera bodies and I need to dig a bit deeper when I can.

--Ken
 
FWIW, I have two updates to share. First, Chris, the author of Downloader Pro did provide me with two responses. I am copying his responses below:


and later


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). 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.

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):
  • 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;
  • DownloaderPro renamed the files with these same times;
  • LR Classic imported these files and shows the same file times;
  • 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,
  • 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);
  • 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)
My conclusions from this latest test are as follows:
  • Both LR and Downloader Pro are reading the dates for renaming correctly and are matching what the camera recorded. Telling the camera that you are in DST automatically moves the time forward on the file by one hour;
  • 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
  • EXIFTool GUI's FileModifyDate field seems to show a -7:00 offset to all files during DST even if the camera has DST set to off and it shows a -8:00 offset to all files recorded during a non-DST portions of the year
I also talked with Microsoft/Github engineer and his first response are that dates are generally a mess and there is not one standard that everybody uses other than to set everything to UTC with no offset. So, it appears that there are at least two attempts to provide useful data about time and DST by the camera companies (the DST flag used by some companies and the time zone/UTC offset setting). Unfortunately, it seems that Microsoft has decided to ignore most of this information and just automatically add an hour to its File Properties dialog box. I have not yet reconciled while my first sample above had a different FileModifyDate, but those samples were from different camera bodies and I need to dig a bit deeper when I can.

--Ken
Thanks for these updates. They confirm my experience that I need to be really careful with Standard Time/DST and photos taken in a timezone other than the one I live in. For the latter, my workaround is to reset the Windows Time Zone. For the former, it's more hit and miss.

Phil
 
I had just a few minutes so I took a couple of shots with the D500 which just had a firmware update today. I took three shots - one at the current date/time, and two with the camera dated last summer during DST. The first had DST setting off and the second had it on. EXIFToolGUI reported the dates as follows:
  • December date (no DST and DST set to off) - FileModifyDate set correctly (Windows shows it 1 hour ahead);
  • August (DST and DST set to off) - FileModifyDate set correctly (Windows shows it 1 hour ahead);
  • August (DST and DST set to on) - FileModifyDate set correctly one additional hour ahead (Windows shows it 1 additional hour ahead)
  • Timezones were all shown as -8:00 and the offset for the files in the FileModifyDate were (-8:00/-7:00/-7:00) respectively
I have not yet tried to rename the files, and will only report back if there is something different than what I just posted above when I do try.

--Ken
 
Thanks for these updates. They confirm my experience that I need to be really careful with Standard Time/DST and photos taken in a timezone other than the one I live in. For the latter, my workaround is to reset the Windows Time Zone. For the former, it's more hit and miss.

Phil
The Windows issue is not too hard to live with since the EXIF info. seems to properly reflect what is in the files and the naming with the time incorporated seems correct. If I wanted a bit more control, I would consider not using the DST flag in the camera and just manually changing the time by an hour. If I really wanted to take more control, I would not change the time zone setting or the DST flag and then, although I am not inclined to do so as I can live with the Windows reporting error (at least for now).

--Ken
 
Status
Not open for further replies.
Back
Top