Skip to main content
Adobe Photoshop Family

475 Messages

 • 

10.5K Points

Mon, Jun 30, 2014 4:49 AM

Lightroom Classic: Changes creation date of image files

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

Responses

475 Messages

 • 

10.5K Points

5 years ago

Hi Mixapix.

Welcome to the Adobe Lightroom (female dog)-a-thon.

I think your options are
a) live with it
b) move to Windows (it appears that this is a Mac-only bug)
c) rename your photos so that they start with the date in YYYY-MM-DD HH-MM-SS format, so you can sort by name and achieve sort by exposure date.

I do the the third.

(Adobe doesn't like the 5-letter word for female dog.)

67 Messages

 • 

950 Points

There are some more options or workarounds:

d) Leave LR (I will)
e) give your photos exif dates if they don't have it yet and copy the exif date back to the creation date (I do this from time to time). ExifTool helps to do both.

Didn't find better solutions. (b) is the best joke ever.

Champion

 • 

5.3K Messages

 • 

95.7K Points

"b) move to Windows (it appears that this is a Mac-only bug) "

LR CC 2015.3 (Windows 10) doesn't preserve file Date Created either. In general, Windows has never had the convention of preserving it, as there has been on Mac.

67 Messages

 • 

950 Points

Sorry, (b) was a joke by me. I would never change back to Windows whatever will happen... :-)

Champion

 • 

488 Messages

 • 

8.9K Points

I'm not seeing this, John. I've run the same tests, many times, on both OSX and Windows10 (adding metadata to a jpeg in Lightroom, then doing Cmd/Ctrl+S), but the Date Created is only updated on the OSX system.

444 Messages

 • 

6.6K Points

5 years ago

I also do the rename with date first, as recommended by The Lightroom Queen I believe! It solves other problems as well, such as exporting without metadata but keeping a copy.

Bob frost

18 Messages

 • 

310 Points

Robert, renaming files to include the date/time in the filename seems like a very good idea as the LR bug seems to be one which won't go away unfortunately. It seems that all stand-alone JPG files (i.e. those without a matching RAW file along with an XMP sidecar), PNG etc. files are affected and won't keep their Creation dates whenever keywords are added/changed. Very frustrating.

I have some good news though, based on a little test I just did in LR. Here's what I did (after inserting the memory card and having the "Import" window show up):

1) (on the right hand side of the window) under "File renaming":
here I chose the format "YYYYMMDD-HHMMSS filename" as keeping the filename will probably make it easier to visually recognize and remember a particular file.

2) "Apply during import". Here I added the keywords I wanted for these particular photos

The result? JPG files imported while being renamed with the shot date (e.g. "20160112-134516 IMG_1241.jpg"), keywords added and the Creation date (as seen in the OSX Finder) NOT being updated to today's date!
That should (as much as possible at least) solve the problem for all new photos from now on. I see the files get updated with today's date when I press CMD-S (save) in LR though, just like before. But at least the files have had their dates copied to the filename!

All in all -the good news is that all my JPG files (among those over 2000 files affected) with Creation dates messed up taken with digital cameras (i.e. containing the necessary EXIF tags) can have the date information restored in the OSX Creation date (using "A better Finder Attributes" with the "Copy EXIF to Creation date" option) and this same information can be copied over to the filename itself for permanently keeping this info no matter what happens with the Creation data again (using "A Better Finder Rename" by creating a custom tag). This leaves the scanned images (which don't have those same EXIF tags) where I assume the scanned date (Creation date) is lost forever unless I restore the files from a backup and quickly copy the Creation date over to the filename before it changes again.

So once I've fixed all affected files as above, is it simply a matter of selecting a folder in LR, right-clicking and selecting "Synchronize folder" to re-import the same photos (but with different names) back into the LR catalog?

UPDATE: in my test I had to turn OFF "Automatically write changes into XMP", or else the JPG Creation dates would be changed to today's date while importing. I'm still debating if having this turned on is a good idea or not -apparently keeping separate XMP files means most of the image edit settings can be restored if the catalog ever crashes (and there's no backup), but I hear some people say the XMP is useless with other software other than LR.

Champion

 • 

5.3K Messages

 • 

95.7K Points

"This leaves the scanned images (which don't have those same EXIF tags) where I assume the scanned date (Creation date) is lost forever unless I restore the files from a backup and quickly copy the Creation date over to the filename before it changes again."

After you restore the scanned files, store their creation date in the metadata ("EXIF") immediately, then you'll never lose the date again, regardless of which program(s) you use. To do that, in LR select all those files. Then edit Metadata > Edit Capture Time, select Change To File's Creation Date, and click Adjust Images. Then you can rename the files if you wish to sort them in the Finder by creation date/time also, but that wouldn't be necessary if you just going to use photo apps to organize your files.

18 Messages

 • 

310 Points

Interesting. I did a quick test and at first glance it seems to work. Indeed, a "date time original" and "Date time" tag was added which previously wasn't present, but of course when adding a keyword the Creation date would be changed to today's date again.
Still, with the date present in the EXIF I can now copy that back to the file Creation date (using "A Better Finder Attributes" where I made a "droplet" which sits in the OSX dock. That way I can just drag and drop the files I want treated and off I go!).
Hmmmm.... seeing this option I can't help but think Adobe acknowledges their blunder (which they apparently won't admit) and still wants people to have the option to fix files manually. IMHO this feature should be done automatically before keywords are written to files not already having these EXIF date tags.

So now I think I know a little more about fixing the mess (which Adobe could easily had prevented if they did things properly) and after restoring the (correctly dated) scanned images from my backup drives) I need to do the following:

1) After scanning images, immediately (definitely before adding keywords as that'll update the Creation date), do a "Metadata-Edit capture time-Change to file's creation date" in LR

2) Now and then, "clean" all images by copying the EXIF date over to the Creation date (using "A Better Finder Attributes"). Normal JPG files already have this information in their EXIF tags, and after the LR "Edit capture time" option, scanned images will also have these tags, so all should be fine. I assume other files where the EXIF tags aren't present won't be affected and be left alone.

3) As an extra safety, rename the image files by adding their Creation dates to the actual filename (using "A Better Finder Rename")

I assume at this stage (after renaming the files) I will have to do a "Synchronize folder" from a root folder with images/sub-folders within.

Have I understood it about right?

I really should have a simpler tool to use for step 1 (creating new EXIF tags where the Creation date is stored). Is there a way I can have an application, script, droplet or whatever in the OSX dock which I can just drag and drop files upon to have the new EXIF date tag created and the Creation date inserted? I know EXIFtool can do a lot, but messing around with the command line every time I have to do some "spring cleaning" with my images just won't do. I need something simple and quick instead.

21 Messages

 • 

300 Points

Hi MX:

Try the command line thing with ExifTool. It's shockingly quick. Just CD to your target directory, and then call the command. About 10 seconds total, and it's off to the races.

I keep a text file on the desktop with the various versions of my script already written out, then just copy and paste them into the command line after I CD to whichever directory I want to fix. CD to DIR, paste, go. Just that fast.
(One version to target Tiffs, one version for JPG's, etc.)
I agree, I wish there were a droplet, (or better yet, that LR didn't foul up the dates in the first place) but failing that, the command line thing with copy+paste works well.

PS--> You can CD to the target directory easily by just typing 'CD (space)' and then dragging the icon of whatever folder you want to target from a finder window into the terminal window. Saves figuring out all the volume info, and is much faster than typing if you're after a folder that's nested 6-8 layers deep.

Do not fear Terminal. It's bloody useful.

18 Messages

 • 

310 Points

Yes, it's definitely useful but it would be even better with a droplet or similar in the OSX dock. Actually I think a script of some sort could be used that way and even adding an OSX "Service" (right click on a file to access Services) to have a task like this done.
What's the actual EXIFtool command for copying the OSX Creation date over to the file, creating those new EXIF date tags?
Would you mind uploading the textfile you mentioned with all those commands here?

Champion

 • 

5.3K Messages

 • 

95.7K Points

"I'm still debating if having this turned on is a good idea or not -apparently keeping separate XMP files means most of the image edit settings can be restored if the catalog ever crashes (and there's no backup), but I hear some people say the XMP is useless with other software other than LR."

For TIFFs and JPEGs, the XMP is stored inside the file; for raw files, it is stored in a .xmp sidecar. Except for your issue of it changing the file creation date, it's definitely worth having enabled, as a last-ditch backup in case the LR catalog fails. Lots of software is able to read XMP metadata (both stored in TIFFs and JPEGs and in sidecars) -- it's an industry standard.

LR's develop settings also get stored in the XMP along with metadatata like dates and keywords, but only LR is able to fully interpret the develop settings.

Champion

 • 

5.3K Messages

 • 

95.7K Points

"seeing this option I can't help but think Adobe acknowledges their blunder (which they apparently won't admit) and still wants people to have the option to fix files manually."

My understanding is that Adobe doesn't see this as a blunder. They fully support industry-standard metadata (EXIF, IPTC, XMP) and as part of that, they expect users to store creation dates in that metadata. The Edit Capture Time's option Change To File's Creation Date is intended to help users transition from using the file creation date to using standard metadata.

So it might not be realistic to get them to admit this is a "mistake". However, if enough users vote on this topic, they might, before the next ice age, decide to implement it as a feature request. Unfortunately, there are only five votes for this topic, and past experience has shown that, when it comes to metadata requests, Adobe is unlikely to make many changes unless a very large number of people express dissatisfaction or Adobe thinks a large number of people will be affected. (I'm speaking from sad personal experience.)

Champion

 • 

5.3K Messages

 • 

95.7K Points

"After scanning images, immediately (definitely before adding keywords as that'll update the Creation date), do a "Metadata-Edit capture time-Change to file's creation date" in LR"

Some scanning software will optionally add an industry-standard metadata field DateTimeDigitized to the images they create. If that field is present, LR will use that as the capture time if no DateTimeOriginal field is present. So you might investigate your scanning software to see if it has that option. That will also allow you to later on distinguish between when an image was scanned and the original image was captured (when the shutter was pushed).

21 Messages

 • 

300 Points

Mix:
Sure, but where would you like me to upload it? I didn't think these forums had filespace?

21 Messages

 • 

300 Points

It has some characters that cause havoc with the forum's parser. There is a typed out version of the script about half way down the thread. (waaaay above here.)

21 Messages

 • 

300 Points

John: Where do you vote on this issue? God knows I consider it an incredibly sloppy bit of coding. It sort of reminds me of the joke about M$ back in the old days: "How many M$ coders does it take to change a lightbulb?" "None. They just redefine darkness as the new industry standard". Calling it 'standard' doesn't mean it's not busted.

Champion

 • 

5.3K Messages

 • 

95.7K Points

It's conceptually a very simple change to make (on both Mac and Windows), and I certainly wouldn't object to the change. But it's not important to me, since I decided a long time ago not to rely on file creation dates -- there are too many programs, utilities, and services on Mac that don't maintain it, and if I accidentally run one of them, I've silently lost all my dates.

Your best shot at getting Adobe to pay attention is to get more people to vote for this topic (and support their vote with substantive details on why it matters to them).

18 Messages

 • 

310 Points

Brian M: I assumed this forum (like most other forums) would allow for attachements, but I see no such feature unfortunately.
Perhaps one of the many file-upload services would do, then post the download URL here? I think there are still a few left that don't need registering etc. but alas I haven't used any of them.

18 Messages

 • 

310 Points

John R. Ellis: about the scanning options; no, unfortunately I don't have any such advanced options with my Brother multifunction printer. I can choose to have the filename dated and/or a common name for all scans preceeding the file number, but that's about it.
Maybe I should create a "drag & drop" dock-droplet for copying the OSX Creation date over to the EXIF "DateTimeDigitized" tag then, for anything I scan, and of course have the scanner software name the file itself with the date. I suppose this would be possible with EXIFtool?

About voting for Adobe to fix this nasty bug: it appears most LR users simply don't care about the altering of the OSX Creation date, probably because they just don't handle their images with anything but LR, or don't yet understand the significance of it in case they need to handle them outside of LR some day, and Adobe it seems (not surprisingly) is all about the $$$ and not going that extra mile to keep the customer happy. So in the end it looks like we have to find workaround like the ones discussed here instead.

Once I've figured out all of this I hope to be able to set up some sort of "fix LR-messed up images" script, droplet or something similar which will perform all the tasks needed in one go. I'm sure that a year from now I won't remember all the details about creating a new EXIF date header for newly scanned files (before importing them into LR) and a different situation for those files as well as JPGs where the EXIF date info should be copied over to the OSX Creation date, and yet another procedure for renaming all files by adding the EXIF date to the file name.
In the end we should be spending more of our time taking photos than mess around with these sort of organizing issues in LR which was created in order to help us do just that :-(

Champion

 • 

5.3K Messages

 • 

95.7K Points

"Maybe I should create a "drag & drop" dock-droplet for copying the OSX Creation date over to the EXIF "DateTimeDigitized" tag then, for anything I scan, and of course have the scanner software name the file itself with the date. I suppose this would be possible with EXIFtool?"

It's certainly possible to use a command-line script. Someone else here thinks they can create a drag-and-drop icon that will invoke Exiftool -- that sounds plausible to me but I don't know how to do it.

Champion

 • 

5.3K Messages

 • 

95.7K Points

5 years ago

Jim Wilde wrote, "I'm not seeing this, John. I've run the same tests, many times, on both OSX and Windows10 (adding metadata to a jpeg in Lightroom, then doing Cmd/Ctrl+S), but the Date Created is only updated on the OSX system."

When LR saves metadata to a non-raw on Windows, it will try to modify the file in place, overwriting the metadata fields and preserving Date Created. But if it isn't able to modify the metadata in place, it will write a brand new file and then rename that file to the original filename, thus setting Date Created to "now". Years ago, Rob Cole and I discovered this on Windows, but we didn't test Mac. (I can't find the original topic describing our tests.)

One way I've found to cause LR to write a new file is to set the caption to be very large (e.g. 250 characters) and do Save Metadata To File. Here are before and after screenshots from File Explorer showing the results (LR CC 2015.3 / Windows 10):


Champion

 • 

488 Messages

 • 

8.9K Points

Thanks. I remember the topic, though wasn't 100% certain about my memory! In effect, then, there are really two similar but not quite identical platform-specific issues?

Under OSX, the Date Created is updated to "now" when adding/changing any metadata and writing back to the file.

Under Windows, the Date Created is only updated to "now" in certain situations (when unable to update the metadata in place), e.g. adding a very large caption.

I'd been running the same tests on both platforms (added keywords, Titles, Captions, Ratings, etc.) and seeing different results, because I wasn't triggering the "unable to update in place" problem on Windows.

Champion

 • 

5.3K Messages

 • 

95.7K Points

I don't know why LR Windows and Mac behave differently on this score -- architecturally, the two OSes are very similar with respect to app use of the file system.

2 Messages

 • 

70 Points

5 years ago

It kinda doesn't matter if PC users can't duplicate it. Be thankful.

When you have 80,000+ pictures going back 15 years of friends, families and events and you suddenly cannot find any of them by the year you KNOW the dates from, all you can do is shrug (and be pissed).

I was trying to be more orderly and name files by familiar English words, and all the dates got changed to the day I renamed them.

All 80,000? No. But enough of the ones I cared about to rename them.

It's terribly sad how this tool that was making my life better actually complicated it in the 2nd worst way — next to losing the images.

18 Messages

 • 

310 Points

5 years ago

I couldn't agree any more. My situation isn't half as bad as yours but still very frustrating. Whatever reason, LR's way of changing Creation dates adds no benefit to anyone, just grief and frustration to those who do care about file Creation dates.

I guess besides laziness and not being willing to admit this is a mistage/bug, Adobe just probably assumes that when you use LR that's the only system you'll ever use to organize your photos.

Do you have a backup of your files with the correct dates?

21 Messages

 • 

300 Points

5 years ago

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<filemodifydate' -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

67 Messages

 • 

950 Points

5 years ago

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

18 Messages

 • 

310 Points

5 years ago

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

21 Messages

 • 

300 Points

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

67 Messages

 • 

950 Points

5 years ago

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

18 Messages

 • 

310 Points

5 years ago

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.

18 Messages

 • 

310 Points

5 years ago

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<filemodifydate' -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<filemodifydate' -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?
 

18 Messages

 • 

310 Points

5 years ago

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

 

67 Messages

 • 

950 Points

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. 

Champion

 • 

5.3K Messages

 • 

95.7K Points

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

18 Messages

 • 

310 Points

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

67 Messages

 • 

950 Points

The last argument in the command line should be the file or folder . In this example this is the dot.

1 Message

 • 

60 Points

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?

67 Messages

 • 

950 Points

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.

18 Messages

 • 

310 Points

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?

Champion

 • 

5.3K Messages

 • 

95.7K Points

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


18 Messages

 • 

310 Points

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

Champion

 • 

5.3K Messages

 • 

95.7K Points

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

18 Messages

 • 

310 Points

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?

Champion

 • 

5.3K Messages

 • 

95.7K Points

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

18 Messages

 • 

310 Points

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.

475 Messages

 • 

10.5K Points

5 years ago

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

18 Messages

 • 

310 Points

5 years ago

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?

5 Messages

 • 

100 Points

3 years ago

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