Lightroom: Changes creation date of image files

  • 10
  • Problem
  • Updated 12 months ago
  • (Edited)
Lightroom 5.5 running on Macintosh Mavericks 10.9.3 clobbers the creation date when modifying a file.

I did the following test: I added a folder of jpgs to Lightroom, and then I added a keyword to all of them. I have "Automatically write changes into XMP" set in my Lightroom catalog. After changing the keyword, the creation date is now set as the same as the modification date which is incorrect behavior (and an important loss of metadata).

It is not necessary to change the creation date to change tags, for instance the command line

% exiftool -overwrite_original_in_place -subject+="Jane Eyre" image.jpg

does not change the creation date, but only the modification date.

See https://forums.adobe.com/thread/1192949 for other reports of this bug, now over 1 year ago.
Photo of Alan Harper

Alan Harper

  • 458 Posts
  • 94 Reply Likes

Posted 5 years ago

  • 10
Photo of Brian M.

Brian M.

  • 21 Posts
  • 2 Reply Likes
Hi Mix,

Here's the script to load the file creation date into the metadata:

Open terminal (make sure you have Exiftool installed)
and CD to your target directory.
Then copy & paste into the command line:

exiftool -r -overwrite_original_in_place '-datetimeoriginal&ltfilemodifydate' -if '(not $datetimeoriginal or ($datetimeoriginal eq "0000:00:00 00:00:00")) and ($filetype eq "TIFF")' .

The period at the end's important. This will update every tiff in the folder so that the creation date is loaded into the metadata, if the image didn't have anything there to start with. If it did, it won't touch it. It will update your creation date to "now" though, so you'll have to go back through with something like "Finder Attirbutes' to reset the creation dates based on the exif data. (Reasoning, comma circular, see Circular Reasoning.) But it works.
If you want to get JPG,s just change the filetype to "JPG". PNG works too.

The good news is that once you actually have creation dates in the metadata, LR will leave at least *that* alone, so you've got a hard point to use to re-jigger the file dates whenever you need to.

This is still a horrific kludge, but it does work. Should we have to do this? No. It's entirely up to inexcusably sloppy coding on Adobe's part, combined with a 'can't be bothered' attitude.
They should go talk to Quark about what happens when you abuse your user base, secure in the knowledge that they have no other options...

Best of luck
-Brian
Photo of Reinard Schmitz

Reinard Schmitz

  • 65 Posts
  • 8 Reply Likes
It's really easier to do all that with A BETTER FINDER ATTRIBUTES. It transfers directly creation or modified dates to where you need them. And it's a nice GUI...
Photo of Mixapix

Mixapix

  • 18 Posts
  • 0 Reply Likes
Thanks Brian M!
So this script creates a new "datetimeoriginal" EXIF tag inside those TIFF files which don't have that already, then follows by copying the OSX file Creation date over to that EXIF tag, but updates the OSX file Creation date to "now" in the end?
Is there no way to prevent it from updating the Creation date?

I suppose the script could be made to do this with the various file types (JPG, PNG and possibly a few others as well) in one go -any ideas on how? Also, does the script dig into sub-folders (and sub-folders within) as well?

Reinard Schmitz: I have A Better Finder Attributes (ABFA) already which is nice, but it doesn't do the above.
Still, it's nice to fixing the file the other way around (read the EXIF date tag, then replace the OSX Creation date with that same date. It also allows you to make "droplets" which are nice to keep in the OSX dock.
I now have a couple of them in my dock: a "Copy EXIF timestamp to Creation date" (ABFA) and another droplet which reads the EXIF timestamp, then adds the time/date to the beginning of the filename (using "A Better Finder Rename" (ABFR)).
Photo of Brian M.

Brian M.

  • 21 Posts
  • 2 Reply Likes
I never managed to get it to leave the file creation date alone, but once I had the date in the EXIF, I didn't care so much, so I stopped sweating it.

The "-R" makes it recursive. It'll get all the subfolders within the targeted directory.

I just have a couple different versions of it (for tiff, & JPG) in a text file that I copy & paste. That's easier than all the screwing around you'd have to do to get it to do multiple file types in one go. Run one cycle for tiffs, one for JPGs, and away you go.

Best of luck
Brian
Photo of Reinard Schmitz

Reinard Schmitz

  • 65 Posts
  • 8 Reply Likes
See the appended picture!

@Mixapix: You are right: If the DateTime Fields are not already there you have to use Exiftool:

# Set the DateTime fields recursively to SystemModifyDateTime for all JPGs
# Set the keyword to 'DateModified' so you can identify these photos later
exiftool -r '-alldates
Photo of Mixapix

Mixapix

  • 18 Posts
  • 0 Reply Likes
Thanks Reinard!
I've typed it all in and hope I have all the spaces etc. correct. And should there be a punctuation (.) at the end of the two last lines?
How do you actually use the script? Should I create a new Applescript document and paste it into there?

I have a bigger problem though: I can't get Exiftool to work for some strange reason. I keep getting an error message (see attached image) after having downloaded and installed it from the official website. I also followed the installation instructions where it says to create a file named ".profile" with a $PATH definition. Still, same error message. Finally I tried to re-install Exiftool from my admin account. Same error message again.

UPDATE: OK, forget about the error screenshot above. I tried installing Exiftool on my Macbook Pro the exact same way and it worked fine there (I entered "exiftool" in the terminal and it responded with a help screen), so something must be wrong with the other Mac. I'll do my testing on the laptop instead.
I could still need some help figuring out how to use the script in a "drag & drop" sort of way though.
Photo of Mixapix

Mixapix

  • 18 Posts
  • 0 Reply Likes
Brian M. wrote:
Here's the script to load the file creation date into the metadata:

Open terminal (make sure you have Exiftool installed)
and CD to your target directory.
Then copy & paste into the command line:

exiftool -r -overwrite_original_in_place '-datetimeoriginal&ltfilemodifydate' -if '(not $datetimeoriginal or ($datetimeoriginal eq "0000:00:00 00:00:00")) and ($filetype eq "TIFF")' .


Unfortunately it didn't work for me. Here's the result (with two scanned JPG files in the folder I just cd'd to):

$ exiftool -r -overwrite_original_in_place '-datetimeoriginal&ltfilemodifydate' -if '(not $datetimeoriginal or ($datetimeoriginal eq "0000:00:00 00:00:00")) and ($filetype eq "JPG")' .
    1 directories scanned
    2 files failed condition
    0 image files read
$

And needless to say the JPG files still didn't get any date info embedded into their EXIF header.
Where did I go wrong?
 
(Edited)
Photo of Mixapix

Mixapix

  • 18 Posts
  • 0 Reply Likes
Reinard Schmitz wrote:

See the appended picture!

@Mixapix: You are right: If the DateTime Fields are not already there you have to use Exiftool:

# Set the DateTime fields recursively to SystemModifyDateTime for all JPGs
# Set the keyword to 'DateModified' so you can identify these photos later
exiftool -r '-alldates


I had a lot of problems getting to work until I found out that the apostrophe I used was wrong. It seems OSX has a number of nearly identical looking apostrophe symbols, so I copied one over from a UNIX commandline I had noted somewhere and it worked! Afterwards I tried overwriting the OSX file Creation date (now mangled by LR) and indeed, it fetched the date/time from the EXIF header and updated the Creation date with the correct date/time! :-)

I don't know if this will come out right for others to use, but here's the commands and the results from my Terminal command line (after doing a "cd" over to the directory with a few JPG scans (the commands I intered (followed by pressing RETURN are in bold while the results are not):

$ exiftool -r '-alldates<FileModifyDate' -keywords+=DateModified  -if '!$datetimeoriginal' *.jpg
    3 image files updated
$ exiftool -delete_original -r .
    1 directories scanned
    3 image files found
    3 originals will be deleted!  Are you sure [y/n]? y
    3 original files deleted
$ exiftool -restore_original .
    1 directories scanned
    3 image files found
    0 original files found
$

 
I assume "_original" are backup copies of the original files so that in case something goes wrong (power outage, computer crash etc.) you won't have lost everything, right?
But it creates additional work and interrupts an automated process by having to answer "y" to delete those files. Besides, investigating them will usually take some time, so how about instead creating an "Original" sub-folder within the images' folder, which will contain "_original" backups of the files?
A separate script could be used to look through all folders/sub-folders and delete all those "Original" folders if wanted, or left alone if wished by the user.

How could all that be done, and how do you combine all the commands above (possibly a modified version for the "Original" folders I suggested) so they can be run in one go? Ideally something which can go in the OSX dock, and accepts the drag & drop of a folder which it will then look through for image files missing EXIF date/time tags.
Oh, it should also handle all types of files in one go which could be missing the EXIF date/time tag (JPG, TIFF and PNG as far as I know).

 
(Edited)
Photo of Reinard Schmitz

Reinard Schmitz

  • 65 Posts
  • 8 Reply Likes
1. if you replace *.jpg by a . (dot) all allowed filetypes will be handled
2. There is only one type of apostrophe (single quotation mark): #39 [0027] on any computer and OS
3. restore_original is used if something got wrong. You can use the -overwrite_original argument in the commands to overwrite the files; no backup will be kept. the backups are always in the same folder as the changed file.
4. You can combine several commands in a shell script and put in on the desktop or where ever. You could google for howto. 
Photo of John R. Ellis

John R. Ellis, Champion

  • 4650 Posts
  • 1254 Reply Likes
"2. There is only one type of apostrophe (single quotation mark): #39 [0027] on any computer and OS"

Unfortunately, it's more complicated than that. Unicode distinguishes between the Apostrophe and the Right Single Quotation Mark.  See this article for details: https://en.wikipedia.org/wiki/Quotation_mark#Unicode_code_point_table

What you get when you type the "/' key depends highly on the operating system, the application, and the encoding you save the file in.  For example, if you use the OS X TextEdit program and type the "/' key and then save the file in encoding UTF-8, you'll get the Unicode Right Single Quotation Mark (U+2019). If instead you save the file with encoding Western (Mac OS Roman), an 8-bit encoding, you'll get the byte 213 (0xd5), which is displayed as a right single quotation mark.   To get an apostrophe (39, 0x27), you have to either cut-and-paste or turn off the Smart Quotes option.
Photo of Mixapix

Mixapix

  • 18 Posts
  • 0 Reply Likes
@John R. Ellis:
Yes, Textedit is what I've been using for writing those terminal commands. Like I said it worked after changing the apostrophe (though I have no idea which ASCII character code this is or how to find out -I just copied it from another note I had). Unfortunately I can't get Brian M's code to work though, despite trying numerous variations of the quote/apostrophe character and turning off the Smart quotes option in Textedit and even manually replacing the quotes/apostrophes in the Terminal.

@Reinard Schmitz:
1) Thanks. So like this, with one space between '!$datetimeoriginal' and .?:
exiftool -r '-alldates<FileModifyDate' -keywords+=DateModified  -if '!$datetimeoriginal' .
And this will only affect image files (and videos?), and not mess up files which aren't supposed to have EXIF data in them? PDF, RTF, TXT etc.)

3) So for adding the new EXIF tag/writing the Creation date into it, all in one go without a backup I could use the single command line as follows?:
exiftool -r '-alldates<FileModifyDate' -keywords+=DateModified  -if '!$datetimeoriginal' . -overwrite_original

4) Good to know. I'm trying to find out more as we speak.
I see myself creating a "manual" drag & drop script for fixing files as I locate them in the Finder, and another script which is automated for fixing scanned files on the go, right after they've been scanned. If I succeed I'll post the results here as I see others struggling in the same way with this LR bug.
(Edited)
Photo of Reinard Schmitz

Reinard Schmitz

  • 65 Posts
  • 8 Reply Likes
The last argument in the command line should be the file or folder . In this example this is the dot.
Photo of Zeljko Soletic

Zeljko Soletic

  • 1 Post
  • 0 Reply Likes
I noticed few years ago that both Lightroom and Photoshop are unpredictably changing some metadata values on Windows system, but today I noticed that Lightroom 5.0 is always changing Capture Time and Capture Date. I do use Exiftool in many cases, but using Exiftool is impossible in my particular case, as I do many changes through different software for the final result, and even file name is not the same. Is there any solution to force Lightroom keeping original Capture Time and Capture Data?
(Edited)
Photo of Reinard Schmitz

Reinard Schmitz

  • 65 Posts
  • 8 Reply Likes
No. But if you have a correct exif date from the camera you can alway copy this back to system creation date/time from time to time as I described above some months before. I do so.
Photo of Mixapix

Mixapix

  • 18 Posts
  • 0 Reply Likes
I've been working hard for a while to get a final and easy to use solution to all of this, and am close to finishing it. If there's still any interest I'll post the results here.
 
In the meantime it would help to determine which files are affected. My tests indicate that JPG and PNG files have both Creation and Modification dates changed while TIF and DNG files only have their Modification dates changed.

RAW
files (I've tested Canon CR2 and Olympus ORF) as well as movie files (MOV and AVI have been tested) are being left alone.

Does anyone have different experiences or can add to this?
Photo of John R. Ellis

John R. Ellis, Champion

  • 4650 Posts
  • 1254 Reply Likes

"My tests indicate that JPG and PNG files have both Creation and Modification dates changed while TIF and DNG files only have their Modification dates changed."

Something to be aware of in your tests: When the creation date is preserved can depend on exactly what changes you've made to the photo within LR and low-level details of how the file was laid out by the camera or software that created it.  So it's very possible that you could observe creation dates preserved for TIFFs and DNGs now, but down the road find in different circumstances they are getting overwritten.  

Ugly details: A number of years ago, a couple of us investigated what LR did when the user modified some metadata (e.g. caption or capture date or develop settings).  We observed that sometimes LR modified the file in place, and sometimes it wrote a new temp file and then renamed the temp file on top of the original.   It appeared that LR would modify the file in place only if it thought there was room in the low-level format for the modified metadata.   Exactly when LR thought there was "room" seemed to depend on the file type and the current layout of metadata within the file (which depends on the data itself and how the firmware or software decided to lay out within the format).   I think we observed this behavior for both JPEGs and TIFFs (don't recall testing DNGs, but DNGs are TIFFs).

When LR modifies a file in place on OS X, the creation date will be preserved. But when it writes a temp file and then renames it, the original creation date will be lost.  (An application needs to take a specific step to copy over the original creation date, and LR, like many newer Mac applications, neglects to do that.)

Unfortunately, I can't find the original thread to verify my recall. But I'd be very leery of ever relying on LR to preserve creation dates.


Photo of Mixapix

Mixapix

  • 18 Posts
  • 0 Reply Likes
It's a pretty confusing issue indeed.
I'm working on a couple of drag & drop Automator script applications based on Exiftool where the first script checks to see if the images contain a "DateTimeOriginal" tag or not. If it doesn't, it (and three other date/time tags) will be added to the file using the OSX file Creation date.
Since Exiftool also works with other files (such as PDF) I want to add some criteria so it'll skip the files Lightroom won't ever mangle the dates of anyway (or it might choke with some error message or spend considerably longer whenever it looks through large numbers of files as different metadata might be expected for those and other files), hence my question about which files LR changes the OSX Creation dates of.

So, you're basically saying that even though I'm testing with a batch of image files in various formats (JPG, TIFF, PNG, MOV, CR2, AVI, DNG etc.) with and without EXIF date tags, I can't fully rely on my results as LR might handle them differently in different situations or with different source files?

With that in mind I still don't think there should be any problem as long as I have the script check any file which LR would otherwise mangle the Creation date of in any situation.

Unfortunately, I can't find the original thread to verify my recall. But I'd be very leery of ever relying on LR to preserve creation dates.
Would you suggest I have it look at ANY image file including video files and all manufacturers' RAW files, and just skip everything else which Exiftool could handle (PDF, Illustrator and a number of other files)?
(Edited)
Photo of John R. Ellis

John R. Ellis, Champion

  • 4650 Posts
  • 1254 Reply Likes
"have it look at ANY image file including video files and all manufacturers' RAW files"

LR will never modify raw files or video files.  (There's an obscure option to have LR write date/times back to raw files, but don't enable that option.)  So from LR's perspective, you only need to worry about JPEG, TIFF, DNG, PNG, and PSD.
Photo of Mixapix

Mixapix

  • 18 Posts
  • 0 Reply Likes
Where's that obscure option to have LR write date/time back to RAW files?
I found an option called "Write date or time changes into proprietary raw files" (Lightroom-Catalog settings-Metadata), but enabling or disabling it made no difference concerning changes to the OSX file Creation and Modification dates.

It appears the only files which have their OSX file Creation (and Modification) dates changed to "now" are JPG and PNG. Apart from that the only "now" Creation dates are with the newly created XMP files. TIFF and DNG files have their OSX file Modification dates updated to "now" while the rest (Canon and Olympus RAW files, MOV and AVI video files have unchanged file Creation and Modification dates. I don't care about the Modification dates, and frankly it's a good thing that they're updated to "now" whenever a change is done internally to the file (i.e. EXIF data, keywords etc. changed or added) because backup software will make a new backup of them, which it should.

To summarize: according to my tests, only JPG and PNG files have their OSX file Creation dates changed (updated to "now") by LR, meaning they're the only two filetypes I need to be concerned about (if I want to keep and be able to restore their file Creation dates).
Can you confirm my findings?
(Edited)
Photo of John R. Ellis

John R. Ellis, Champion

  • 4650 Posts
  • 1254 Reply Likes
"I found an option called "Write date or time changes into proprietary raw files" (Lightroom-Catalog settings-Metadata), but enabling or disabling it made no difference concerning changes to the OSX file Creation and Modification dates."

When I enable that option, use Metadata > Edit Capture Time to change the date of a raw file, and then do Metadata > Save Metadata To File, I see the file Date Modified change to "now" but the Date Created remain unchanged.   I think this is a result of LR's general strategy of trying to change files in place.  In the case of capture time, it's a fixed length field in the raw file, so it's easy for LR to simply overwrite that field without rewriting a brand new file/renaming.  

"according to my tests, only JPG and PNG files have their OSX file Creation dates changed (updated to "now") by LR, meaning they're the only two filetypes I need to be concerned"

As discussed above, there's a possibility that LR will sometimes change the creation dates of TIFFs and PSDs, and your tests may not uncover that possibility.  I'm fairly familiar with the JPEG format and why LR finds it easier to sometimes/usually/often rewrite a new file and rename it rather than update it in place.  I'm not as familiar with TIFF format, but I do know that applications have more flexibility in where to put metadata.  LR appears to put metadata at the end of the file, making it easier for it to modify the file in place.   But applications are free to put metadata at the beginning of the TIFF, and I don't know how LR would handle that situation if the new value of a metadata field didn't fit in the space allocated -- would it modify the file so that the metadata section is now at the end, leaving the old metadata as unused space at the beginning?   Or would it punt (as it often does with JPEGs) and simply write a new file and then rename it (forgetting the date created in the process)?  Don't know.
Photo of Mixapix

Mixapix

  • 18 Posts
  • 0 Reply Likes
It all boils down to finding out if a certain file-type can possibly appear without any EXIF date-tags.
Personal experience with my current scanner at least tells me that I can have scanned images (all without any EXIF data as the scanner apparently doesn't create any such tags) saved as JPG, TIFF or PNG (also PDF or BMP -neither being a concern as LR doesn't support them), so my "Add EXIF date tags if not already present" script would have to support those files for sure (JPG, TIFF, PNG). PSD files, as it's possible to create a file from scratch, and without any photographic content  (thus no EXIF data) would have to be included as well.

IMHO, RAW files are and should always be read-only, but then again -is there such a thing as a RAW file without date-tags, and don't they all originate only from digital cameras? I have to ask the same about DNG files, because as far as I know they're just RAW files converted to generic, more compatible format.
(Edited)
Photo of Alan Harper

Alan Harper

  • 458 Posts
  • 94 Reply Likes
Just a quick comment on the solutions being offered here.

The "Date Time Created" exif field is "the date (and optionally, the time) the photograph was created, not the date when you scanned or edited the image". The creation date of a file is the date that the file was created. These are distinct data, and I think running a script to replace one with the other is fundamentally misguided. (If I create a Photoshop file from a raw file, the raw and Photoshop files will have different creation dates).

The only way I can think of maintaining the create date is to make a backup of your files (either the files themselves or a text file with the dates), and then run a script that first copies the create date from the backup to the originals (when they differ) before updating the backup. Of course, you would need to start that process before adding photos to Lightroom. And there would be lots of edge cases that will fail anyway.

Or you can, like I have, just give up on the idea of a stable creation date. Other processes also poison create dates (like backing up to the web and then re-downloading the file). And I was burned when an early version of "Path Finder" (a Mac Finder replacement that I have used for years) replaced the create date with the current date when I had to restore from a backup after a hard disk went south.

I lost most of my creation dates in that fiasco, since I didn't realize what had happened until I had overwritten the backup with the restored files. (The bug in Path Finder was subsequently fixed with profuse apologies — very different than Adobe's attitude I must say).

A
Photo of Mixapix

Mixapix

  • 18 Posts
  • 0 Reply Likes
Good catch, Alan!
It gets confusing with all these tags, so I decided to find out what the four tags I'm creating with Exiftool corresponds to in LR:

DateTimeOriginal (ExifIFD): "Date Time Original" in LR (EXIF section)
DateTimeDigitized (XMP-exif): "Date Time Digitized" in LR (EXIF section)
CreateDate (ExifIFD): I can't find this date/time anywhere in LR!
ModifyDate (IFD0) = "Date Time" in LR (EXIF section)

I figured out the above by manually adding those tags with Exiftool, each one with a unique date/time. I then imported the image-file into LR where I compared the various dates with what their tags were called in Exiftool's analysis of the same file.


Next I created a copy of that file, imported that one into LR as well, added some metadata (a color label in this case) and saved it (CMD-S). Then finally opened it in Exiftool too, comparing it to the original file (the one not had any metadata saved to it by LR). It contained numerous new tags along with several of the existing ones and some dates/times moved around to other tags. Here are all the date/time related tags found in that (metadata LR-saved) file:

DateTimeOriginal (ExifIFD): old tag, with same date/time as before
DateTimeDigitized (XMP-exif): old tag REMOVED. Its date/time is however transferred to "CreateDate" (ExifIFD)
CreateDate (ExifIFD): old tag, but now has the date/time CHANGED to that of "DateTimeDigitized" (XMP-exif). The date/time originally present in "CreateDate" (ExifIFD) is completely GONE, not to be found in any other tags! Obviously not used by LR as it wasn't even visible with the original file either
ModifyDate (IFD0): old tag, with same date/time as before. Its date/time is also found in the newly created "ModifyDate" (XMP-xmp) tag
ModifyDate (XMP-xmp): new tag, with same date/time as in "ModifyDate" (IFD0)
MetadataDate (XMP-xmp): new tag, shows the date/time when I pressed CMS-S (to save the file's metadata) in LR. Same date/time as in "HistoryWhen" (XMP-xmp)
DateTimeCreated (Composite):new tag, with same date/time as in "DateTimeOriginal" (ExifIFD)
DateCreated (XMP-photoshop): new tag, with same date/time as in "DateTimeOriginal" (ExifIFD)
DateCreated (IPTC): new tag, with same date (only date) as in "DateTimeOriginal" (ExifIFD)
TimeCreated (IPTC): new tag, with same time (only time) as in "DateTimeOriginal" (ExifIFD)
HistoryWhen (XMP-xmpMM): new tag, with same date/time as in "MetadataDate" (XMP-xmp)
CreateDate (XMP-xmp): new tag, with same date/time as in "CreateDate" (IFD0)

That's quite a few tags to keep track of. If needed I could assign the Exiftool-based script to create some of those new tags with the OSX file Creation date if not already present. But we first need to figure out which tags are "out of bounds" or "protected" if you will so it won't cause more harm than good.
You mentioned the "Date Time Created" EXIF tag (I assume you're referring to "DateCreated" (IPTC) as the link you put in there says, correct?) being when the photo was actually taken, not scanned or edited it. I'm guessing this refers to, say a photo from 21st August 1955 which has been scanned on the 1st of January 2016, and obviously this isn't something which can be timestamped automatically. I assume it's found somewhere in LR, and has to be manually entered there along with any other metadata (keywords, labelling, rating etc.), but where?
.... Hold on.... I think I found it in the IPTC section (obviously) under the "Image" section and says "Date created". It currently holds the same date/time as seen in "DateTimeOriginal" (ExifIFD) albeit in a different format. Since there's no selection mechanism (i.e. clicking on a range of numbers for each section of the date) you'd have to be careful so you don't make any mistakes when writing it.

OK, so I can change the script so that if "DateCreated" (IPTC) is found it will be left alone. But if it's not found it will be created with the OSX file Creation date used. Does that sound like a solution for that tag?
Would there be any need for such a "safety mechanism" for those other date/time tags as well (DateTimeOriginal (ExifIFD) is already covered)?:

DateTimeDigitized (XMP-exif) -same tag name in LR
CreateDate (ExifIFD)  -not used by LR
ModifyDate (IFD0) -"Date Time" tag name in LR

... in other words, tell my script to check the first of these tags, if it's present in the file; and if yes, do nothing and check the next file.


Files, tags and other technicalities aside....
Since I found out about Adobe's blunder I've started to add the date to the actual filename in addition to the original filename (i.e. 20160507-183439__MG_2413.CR2) while importing. I've also renamed some of my old images (the ones I'm sure haven't had their dates mangled by LR) and will continue to do so with the rest (as soon as I've worked out this script for adding those date tags and restoring those with EXIF tags but a messed up file Creation date). That should ensure the safe-keeping of date the image was shot at least.

Regarding Path Finder: I haven't used it a lot yet though I have a version 6 license (came as part of a discounted software bundle). Can you remember which version you had with that nasty bug?
(Edited)
Photo of J.R. Harvey

J.R. Harvey

  • 5 Posts
  • 0 Reply Likes
I am adding my voice to those who are disappointed to find that even a small change, such as writing a new keyword to the metadata causes Lightroom to wipe out the Mac OS file creation date, which is otherwise preserved by PhotoShop. This is with the latest version of Lightroom CC Classic

PhotoShop file, before Lr added the new metadata:

stat -f "Access (atime): %Sa%nModify (mtime): %Sm%nChange (ctime): %Sc%nBirth  (Btime): %SB" "3461A-Edit.psd"
Access (atime): Nov  9 04:01:22 2017
Modify (mtime): Nov  8 19:12:32 2017
Change (ctime): Feb  5 05:24:25 2018
Birth  (Btime): Nov  8 19:12:32 2017

After adding a keyword in Lr which was written to the psd's metadata:

stat -f "Access (atime): %Sa%nModify (mtime): %Sm%nChange (ctime): %Sc%nBirth  (Btime): %SB" "3461A-Edit.psd"
Access (atime): Feb  5 18:38:31 2018
Modify (mtime): Feb  5 15:32:53 2018
Change (ctime): Feb  5 15:32:53 2018
Birth  (Btime): Feb  5 15:32:53 2018
Photo of Philip King

Philip King

  • 21 Posts
  • 3 Reply Likes
Has anyone here tested whether this is still an issue in Lightroom Classic CC (v8.0)?
Photo of John R. Ellis

John R. Ellis, Champion

  • 4650 Posts
  • 1254 Reply Likes
Just tested LR 8.0 on Mac OS 10.13.6, and LR still changes the creation date in some cases.  E.g. when you modify the metadata of a JPEG, LR may create a new file from scratch, setting the creation date to "now".  But usually when you modify the creation of a TIFF, LR modifies the existing file rather than writing a new copy, so the creation date doesn't change.

In my own opinion, I think it is unlikely Adobe will ever change this behavior, for reasons discussed extensively in this topic.