File Renaming/EXIF Data Bug?

[Replytoken]

While I use Lightroom Classic for DAM and post processing, I handle all of my file renaming during culling and prior to import. The program that I previously used is no longer supported, and I have switched to Breeze Systems Downloader Pro to rename and back up files prior to import. I just ran a few tests to get my new file naming correct with their program and noticed an odd glitch that is appearing on some renamed files (primarily from my Olympus E-M1 Mk I, but not all of the camera's files). The program is set up to rename the files with the date and time the image was captured (and I do realize that there are at least three dates associated with any image file). The file renames properly, but when I look at the file properties in Windows Explorer or in FastStone Image Viewer, the Date/Time displayed in these programs reads one hour ahead. When I read those files with EXIFTool (GUI) or with Jeffrey Friedl's Image Metadata Viewer, the dates read correctly. Also, the dates/times in the original raw files read fine.

I am trying to pinpoint the issue and have written the author of Downloader Pro, but have not yet received an answer. I am suspecting that the renaming is causing some change in the file, but since two programs read the dates correctly and two do not, I do not know where the problem lies. Any thoughts?

--Ken

 

[Replytoken]

Well, I have been digging around a bit and found the following articles. I do not know if this explains the issue, but I am suspecting that this must be it because our SD cards use the FAT file system.

https://freefilesync.org/forum/viewtopic.php?t=7866

https://freefilesync.org/manual.php?topic=daylight-saving-time

https://www.codeproject.com/Articles/1144/Beating-the-Daylight-Savings-Time-bug-and-getting

--Ken

 

[Growltiger]

It sounds as if you want to name your files with the date and time the photo was taken?
While that sounds an interesting idea I wonder if there is much point in doing it.
There have often been issues with various programs that import photos and do clever things.
Why not simply copy the files using File Explorer and then do the culling keeping their original file names. Once in Lightroom you can see the times the photos were taken, on the right side, as Date Created.

 

[Walter Rowe]

I agree with Richard. Date in filenames can be helpful, but time stamp isn't. All that info is in EXIF data inside the file, and DAM software packages use the EXIF data/time for date/time oriented sorting and filtering.

Take a look at Photo Mechanic for culling / importing.

 

[Mike Buckley]

I have always used a file renaming convention that includes the date but never the time and I've never experienced any problem except the one time the catalog software I use had a bug that renamed the files not in the order they were captured. Once that bug was fixed, no more problems. The renaming I use occurs during the process that transfers the image files from the memory card to the computer.

 

[gchappel]

+1 for photomechanic.
My version was so old, it was no longer supported. I had to buy a new full version for the new computer. Thought about it for about 2sec. The program just works- and it is fast
gary

 

[gchappel]

By the way, I always include the date imported in the actual file name, it has saved my bacon a few times over the years.
Someone will ask for an old image, and if the metadata was stripped by whatever viewer they were using- the actual file name let me find it!!
So my files are named: XXXXXX date sequence. For example: StAugustineBeach 010822 00001
Works for my workflow, does not mean it would work for yours.
gary

 

[Mike Buckley]

StAugustineBeach 010822 00001

I'm surprised the date expressed in that order of the month, day and year doesn't occasionally cause you a problem. That date would be expressed in my naming convention as 2022-01-08.

 

[gchappel]

I just have always done it this way. I only need it every year or two, but it has saved the day (no pun intended) a couple of times.
gary

 

[Mike Buckley]

I only need it every year or two

Now that I think about it, I've never used the date in the filename to look up a photo. Instead, I use the date in the EXIF data to do that. The only reason I include the date in the filename is that, when combined with a sequential number, doing so ensures that all filenames are unique.

 

[acnomad]

+1 for Photo Mechanic. I don't know what I would do without it.

A couple thoughts follow. Perhaps you'll find something useful within...

1. I used to rename using date and time (YYYYMMDD_HHMMSS_Subsecond) but the filenames are too long to display in certain applications and circumstances. Also, they are not a guarantee of unique filenames when shooting in bursts unless you include the subseconds, which becomes a hassle even within native file management applications.

2. Changing time zones with travel (and often forgetting to change the camera's clock accordingly) frequently results in needing to amend the capture time after the fact. This is particularly important when GPS data is recorded separately, something I always do, as only one of my cameras can geotag at time of capture.

3. To ensure no duplicate filenames, I now use a descriptive name appended before the camera-assigned filename (e.g., Field_Trip_ABC_1234).

In place of the user-defined three characters ("ABC"), I use a code that tells me the year and the camera body used. If I exceed 9,999 images with that body within the year, I change the 3-character code, or if it is near the end of the year, I append a "1" to prevent duplicates from rolling over to 0001.​

​

4. There are various applications available that manipulate EXIF data using Phil Harvey's ExifTool as an engine, in ways beyond what Lightroom and Photo Mechanic can do. I use one called JExifToolGUI. It is extremely powerful, offering an enormous amount of ability to tailor your EXIF data to your needs.

 

[Replytoken]

Thank you for the replies. I am aware of the powers of PhotoMechnic, but Downloader Pro offers what I need for renaming and backup and is somewhat similar to what I previously used. I do not believe that what is happening is a bug of Downloader Pro, but rather an issue in Windows, and one that I might just ignore. But, I would like to know what is triggering the issue when the file is renamed. And it does not matter what new name I choose, the act of renaming must cause a change that doe snot disturb the EXIF info, but how it is read by the OS.

File naming is quite personal, and I have given it a lot of thought over the years after spending a lot of time reading through Peter Krogh's DAM books. I have always incorporated files dates for file management outside of LR. I often create derivative files and share them with folks, and the dating helps me to quickly locate other copies inside or outside of LR. The addition of the time to the name is replacing the unique sequential numbering that I previously added to files so they still have unique names. Downloader Pro has a very nice way of dealing with burst shots in the same second that does not rely on subseconds, and that was one of the features that I liked about it, among others. But as I said above, the actual name is not the cause of the issue; it seems just the act of renaming is.

This is more an annoyance since LR reads the EXIF info correctly, as do programs like EXIFTool GUI. And Downloader Pro renames the files correctly with the appropriate time in the name. So, I believe that it is mostly a Windows quirk that I was hoping to better understand, but I could be mistaken.

--Ken

 

[Mike Buckley]

It wouldn't be the first Windows quirk.

 

[acnomad]

mostly a Windows quirk that I was hoping to better understand

Is it possible associated with daylight savings time? Or does it always happen?

 

[Replytoken]

It wouldn't be the first Windows quirk.

I am not far from Redmond and we are fond of saying, "That's not a bug, that's a feature!".

--Ken

 

[Replytoken]

Is it possible associated with daylight savings time? Or does it always happen?

Yes, the links above indicate that DST is handled differently between NTFS and FAT, and that can cause problems. And I believe that this file was taken during DST. I need to try other methods of changing the file name to see if just the act of renaming triggers the issue. Again, it will not interfere with renaming or with what I am seeing in EXIF data, but what I would like to know is where does Win10 pick up the date for the File Properties box, and does it only make these adjustments when we are not in DST?

--Ken

 

[Growltiger]

It is worth asking yourself what time you really want to put in the filename. If you want to never hit problems, you might consider using the time without the DST, even when DST applies. If you choose to do that, perhaps it is no longer a bug (I can't work out whether to add or subtract).
The logic behind my suggestion is that if you are taking photos around the time DST ends (in the autumn) then your photos will be named in the wrong order, and possibly have identical filenames. If DST ends at 2am and the time at that moment time goes back to 1am, then a photo at 1:10 will appear later than a photo taken 55 minutes later named at 1:05, causing confusion. I realise you could simply accept incorrect times.
If you travel and change time zones things can get much worse. In that case it is safest to simply stick to UTC. (I always leave my cameras set to UTC.)

 

[Growltiger]

what I would like to know is where does Win10 pick up the date for the File Properties box, and does it only make these adjustments when we are not in DST?

--Ken

File times in NTFS files are all stored as UTC, and therefore work logically and consistently across the planet. Windows adjusts the times when it displays them, by taking account of your time zone and DST. So the same file will show different times depending on the time zone and DST of the computer looking at it.
But when it meets a FAT file it has no way of knowing the UTC time and only knows the local time when it was stored. It cannot know whether it is DST or not as it doesn't know which country it was made in. You might have been sent the file from another time zone as well. So it just accepts it as your local time.
It all gets horribly complicated so we are lucky that we have one world standard for time, UTC. A great achievement, given that there are at least three different calendar systems across the world.

 

[Replytoken]

File times in NTFS files are all stored as UTC, and therefore work logically and consistently across the planet. Windows adjusts the times when it displays them, by taking account of your time zone and DST. So the same file will show different times depending on the time zone and DST of the computer looking at it.
But when it meets a FAT file it has no way of knowing the UTC time and only knows the local time when it was stored. It cannot know whether it is DST or not as it doesn't know which country it was made in. You might have been sent the file from another time zone as well. So it just accepts it as your local time.
It all gets horribly complicated so we are lucky that we have one world standard for time, UTC. A great achievement, given that there are at least three different calendar systems across the world.

Point well taken on how DST is a PITA, but the odds of of my shooting at 2AM are somewhat remote. Prior to all of this, I had assumed that local times were always honored, and I believe that for the most part as they are stored as EXIF data they are. Since the local time, assuming that it is set correctly in camera, is used to create the file name, it is "baked" into the file at its most useful point for me. And it seems that the EXIF dates align with that time, so this really is more an annoyance than an actual problem. But, Downloader Pro must be modifying the file in some manner that is causing Win10 to read that date differently.

--Ken