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

21 Messages

 • 

300 Points

5 years ago

In Re: Bob,

At least in my case, I've got images going back almost 25 years. LONG before there was any meaningful implementation of any sort of image metadata. So for those images, file creation date is the *only* way to keep track of which ones came first. They don't *have* any metadata. At the time they were created, relying on the file system was the only game in town.
Which also means that if LR corrupts that file system data, I'm screwed. Believe it or not, I do still reference some of those images, even still.

Arguing about what we *should* do, moving forward, in terms of how we organize our data doesn't help people like me with large, long-term image archives. I've already got tens of thousands of images where I have no choice but to rely on the file system date. After all, it worked just fine for 25 years, across ?5-6? major OS changes, about a dozen different boxen, and 11 versions of photoshop. Why does LR get to break the system?
(I think this all started out on Mac System 6. Been a while...)

At least for me, this is specifically a Mac issue. I'm not greatly interested in how the PC or explorer handle that information. I go back far enough that my attitude on that could be summed up by "of *course* windows screws it up. It's windows."

As I said before, I'd be perfectly happy with a little applet that you dump files on, and it takes the file system file creation date and loads it into the metadata file creation date.
I'd like to see LR fixed, but I'll settle for getting all my data correctly coded so I don't have to worry about it again.

I'll take a swing at John Ellis' method tonight, and see how that works. It may solve the problem.
Or at least provide a workaround that works well enough. (many thanks)

The Ryan M. Exiftool cheatsheat seems like it may have just what I need too. I'll take a swing at that too. One of them may work...

Regards,
Brian

21 Messages

 • 

300 Points

5 years ago

Report from later:
John Ellis' method does work. Takes some fiddling around, but it does work.

There's also a script for EXIFTool on the Ryan M. cheat sheet page that works as well.
The only hitch is that it creates both a modified and original file. So just delete the originals after you import (and test) the modified versions.
Paste this into terminal once you've CD'd to the correct directory:

exiftool '-datetimeoriginald still like to see LR fixed though.

Thanks
Brian

21 Messages

 • 

300 Points

5 years ago

whoops. The forum ate the script.

I'll try to re-post it below.

exiftool '-datetimeoriginal

21 Messages

 • 

300 Points

5 years ago

Really doesn't seem to like the script.

Follow this link:
https://ryanmo.co/2014/09/28/exiftool...
Then look for
Update any photo that doesn't have DateTimeOriginal to have it based on file modify date

That'll get you there.
-B

444 Messages

 • 

6.6K Points

5 years ago

Another alternative that I have used is to rename the files whose old create dates you want to keep, by using the LR rename to incorporate the Capture/create date and time. OK the filename is also just part of the file system, and not part of the actual file, but it is less likely to get changed by anything than the filesystem dates.

I've recently followed Victoria Bampton's (Lightroom Queen) advice and renamed all my files by putting date-time in front of each filename.

But with my old transparencies, I don't have precise capture dates (other than the camera Exif dates when I re-photographed the transparency), so I manually add the date on the transparency to the filename.

21 Messages

 • 

300 Points

5 years ago

I think the various solutions above have set me up to solve my problem, to the extent that it can be solved, but just for the sake of completeness, please follow along here, in regards to any suggestions of renaming:

We can't.

Please remember that this is an image archive going back nearly 25 years. Tens of thousands of images. Images which are referenced *BY NAME* in other files. (Quark, InDesign, etc. Thousands of them.)

The only solution that will work is to add metadata fields to the files that lack them (most) and then load the original filesystem creation date into the creation date in the new metadata. Screwing around with the names is not possible. Hand-editing the date info is not going to happen. It has to be an automatic process.

I just wish this level of fussing wasn't necessary. It's a simple thing really: don't screw up the file origination date when you touch it. Simple. Normal. Good, basic programming practice. (that most other Adobe products follow....)

-B

67 Messages

 • 

950 Points

Ist really simple. Don't touch the creation date... Really. And no excuses, no further explanations.

Champion

 • 

5.3K Messages

 • 

95.7K Points

5 years ago

To clarify so that everyone is on the same page with regards to facts, the OS X filesystem proper does not automatically preserve creation dates when files get copied or new versions get created. With regards to creation and modification dates, the filesystem is similar to that of Unixes and Windows.

Rather, by convention, many if not most Mac applications try to preserve the creation dates of files when they create new versions of the file, even when creating a new version by writing a brand new temporary file (with a new creation date) and then renaming it on top of the previous version. Some of the application libraries and frameworks that developers use provide support to make this easier (though it's not that hard in any case). But preservation of creation dates is not something that is automatically done by OS X -- the developer has to take extra steps to make it happen. Clearly, LR's developers have not taken that extra step.

This convention does not appear to be documented in Apple's developer documentation and application guidelines.

As I described above, not all Mac apps preserve creation dates for new versions of files. Of the modest set of applications on my computer, Google's Picasa and Apple's iPhotos don't preserve creation date, but all the others do, including Photoshop, Bridge, and Acrobat. I found online bug reports from a few months ago where Synology network attached drives don't properly maintain creation dates. The low-level command-line tools like "cp" also don't preserve creation dates.

67 Messages

 • 

950 Points

I think you are wrong. Using Finder

1. Duplicates get the same creation an modified date on the same volume
2. Copied versions on another volume keep creation and modified as well
3. Only the added date and time have the date/time added if you use the duplicate command - or no values :-(

I just double-checked it.

(OS X 10.5.5 b)

Champion

 • 

5.3K Messages

 • 

95.7K Points

Yes, the Finder preserves creation dates. But it does so because it takes explicit, application-level steps to do so, not because the underlying OS X filesystem automatically preserves creation dates.

You can observe that the filesystem itself does not automatically preserve creation dates by running a command-line tool like "cp" or "exiftool" in the Terminal window.

It's important for those wishing to preserve their creation dates to understand this distinction between applications and the filesystem. Because the dates are not automatically preserved by the filesystem, applications must take explicit steps to preserve the dates (or use libraries that do that for them). This makes it more likely that some applications, especially those like LR, Picasa, Dropbox, or "exiftool" that are ported to multiple platforms, will "forget" to follow the Mac conventions.

21 Messages

 • 

300 Points

5 years ago

Solution found: Exiftool comes to the rescue again.
Since it seems not to like me posting scripts, I'll save the script to the end.
But the short version is to CD to a target directory, then use a modified version of the script above, modified to be recursive, an then do a recursive exiftool 'delete original' to clean up the extra files.
At the end of the command, the example will be set to TIFF. If you want to go after JPGs, switch it to JPEG. I've tested it with both, and it works with both. Haven't quite had the guts to try the EPSs yet.

John: why are we arguing file system behaviors? What I can tell you is that the files have survived 25 years with uncorrupted creation dates. That's really all I care about, not the minutiae of *why*. Some of these files are so old they go back to the original Mac file system which didn't need extensions. In fact, we were pretty aggressive about deliberately not using them, just to piss off the PC users. Much fun with those now.
I think I've even got a few files that got salvaged off of my old Lisa and Apple 2. So the minutiae of the file system are of no great interest to me. What matters is keeping the collection integrity intact.

Anyway, here's the script. Enjoy. Run the first part, then run the second, that'll clean up the duplicate 'original images'. Many thanks to my buddy Jeff who helped me iron out the mods.

-B

exiftool -r '-datetimeoriginal .

exiftool -r -delete_original .

Champion

 • 

5.3K Messages

 • 

95.7K Points

Brian observes, " What I can tell you is that the files have survived 25 years with uncorrupted creation dates. That's really all I care about, not the minutiae of *why*."

For those wishing to preserve their files' creation dates, especially others reading this thread in the future, I think it's important to understand how OS X and its ecosystem of applications behaves now. Ignoring the "minutiae" could easily lead someone to lose dates. And given how many people don't have functioning, tested backups, that could lead to disaster.

Because the dates are not automatically preserved by the filesystem, applications must take explicit steps to preserve the dates (or use libraries that do that for them). This makes it more likely that some applications, especially those like LR, Picasa, Dropbox, or "exiftool" that run on multiple platforms, will neglect to follow the Mac conventions. (Even Apple didn't follow its own conventions with iPhotos.)

You've been fortunate that such problems haven't struck you until now (with LR). But consider some other scenarios:

- A friend writes you a script using standard OS X command-line tools like "rsync" or "cp" to reorganize your file storage. Ooops.

- You follow the advice of large numbers of people in these forums and run a script with "exiftool". Oops.

- You read the blog of Jeffrey Friedl, a highly respected LR plugin developer, and try using Picasa to do face recognition on your LR 5 library. Oops.

- You run GeoSetter in Parallels to get additional geotagging features not provided by LR. Oops.

475 Messages

 • 

10.5K Points

Hi John

The issue that you are addressing is that when a new file is created, it has a create date for that date, which seems to me to be the "correct" behavior.

With regard to exiftool, it is designed to create new files when making changes to metadata, so the create date changes, because the output file is a different file than the input file. Exiftool has a switch for exactly this purpose, overwrite_original_in_place, that reuses the same file for output, which preserves the create date.

Similarly, the unix command-line tools do exactly what one expects. "echo 'text' > > file.out" appends text to a file, changing its modify date, but not its create date.

The issue is that Lightroom gives you the illusion (I suspect) that you are using the same file, but (I suspect) sometimes creates a new one and then forgets to restore the create date. This is a Lightroom problem, not a Macintosh problem, although conceivably differences between Windows and Macintosh could cause the same algorithm to have different outcomes, and this could explain why this is a problem on Mac and not Windows.

A final point, not exactly relevant to this discussion, but perhaps useful for those trying to figure out what is going on with Mac create dates. If you duplicate a file using Mac, it will give a create date of "right now" to the new file. However if you drag a file from one disk to another in the Finder, the new file will be a duplicate of the old file, but will retain the old file's create date. This is neither intuitive nor consistent, but I'm pretty sure that is how it works.

67 Messages

 • 

950 Points

>> A final point, not exactly relevant to this discussion, but perhaps useful for those trying to figure out what is going on with Mac create dates. If you duplicate a file using Mac, it will give a create date of "right now" to the new file.

This is nor true as I pointed out somewhere here today. Duplicating retains the creation date in any case.

475 Messages

 • 

10.5K Points

Sorry! Reinard is completely correct.

67 Messages

 • 

950 Points

Not on my MacBook with 10.10.5...

Champion

 • 

5.3K Messages

 • 

95.7K Points

Alan wrote, "The issue is that Lightroom gives you the illusion (I suspect) that you are using the same file, but (I suspect) sometimes creates a new one and then forgets to restore the create date."

That's right. When most programs create a new version of a given filename, e.g. when you do File > Save, they first write the new version to a temporary file, then rename that temporary file back to the original filename. This ensures that if the computer crashes part way through writing the new version, you're not left with a half-written corrupted file.

When first written, the temporary file will have a create date of "now". Applications that conform to the Mac conventions will then explicitly change the temporary file's create date to that of the original file. To the user, this gives the appearance there is one file, with an unchanging create date, that is continually getting updated. But in fact, at the filesystem level, every time you do a File > Save, you're getting a new file created with an initial create date of "now".

While other applications like Photoshop ensure that they explicitly set the create date of the temporary file to the original create date, LR "forgets" to do that.

Alan wrote, "Exiftool has a switch for exactly this purpose, overwrite_original_in_place, that reuses the same file for output, which preserves the create date."

This switch is dangerous, since if the computer crashes partway through, or if Exiftool encounters a bug, you'll be left with a half-written, corrupted file. Unlike Photoshop or other Mac apps, Exiftool doesn't first write the new version to a temporary file -- it writes directly to the original file.

475 Messages

 • 

10.5K Points

I actually don't think it is that dangerous. exiftool writes the changed file to a new file with _exiftool_tmp appended to its name, then copies the bits back to the original. If your computer crashes in the middle of this (rare), and if you don't have backups (stupid), then you would have the temp file which you could rename.

Champion

 • 

5.3K Messages

 • 

95.7K Points

But if the computer crashes, you'd have to do some careful examination to see if it crashed while writing the _tmp file (in which case the _tmp is invalid and should be discarded) or while copying the _tmp file back to the original (in which case the original should be discarded and the _tmp file renamed to the original). If you were processing a large folder of pics during the crash, you'd have to remember to look!

21 Messages

 • 

300 Points

Yeah, but for most people, the EXIFtool update will be a one-time thing, to get the archive up-to date with a current file format. Even with the 'update original in place' flag set, EXIFtool still updates the creation time to current, but I don't care so much: the original creation date has been loaded into the metadata (which the image now has), where it's much safer, and less likely to get banjaxed by sloppy coding. Worst case, dupe the directory via file system (not CP) and then delete the copy once you're sure everything's good.
The odds of it blowing up during a one-time file update, on a cloned directory, are trivial.

Normally, I do a DIFF when pulling things off the old CD's. That won't work here. But you get the idea: check, verify, *THEN* delete. If it does all go south during an update, don't waste time trying to figure it out, just nuke the working directory, and start over from the original.
This is mostly so I can find the JPGs and TIFFs that're scattered through the whole archive. The prepress, PS, and EPS files won't be changed, so most of the critical chronology is unaffected.

Note to the future: the exiftool command to do the update with the original in place, which saves the delete step is:

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

-Brian

Champion

 • 

5.3K Messages

 • 

95.7K Points

The Exiftool script looks like it should be very helpful for others. For anyone else reading this, can you give some details why you went with the script rather than using LR's Edit Capture Time command? (I have a bias in favor of Exiftool myself, but details would be good...)

21 Messages

 • 

300 Points

Two reasons:
A) don't trust LR not to foul it up again, and (B) I've got directories nested 6-8-10 layers deep.
Doing it from the command line gets them all, with no questions asked, quickly and dependably. I'm going to do segments of the archive at a time, just so if there *is* a problem, it doesn't take out the whole thing.

I also haven't quite decided how I'm going to handle the update. This is a prepress archive, so there are all sorts of files in there that LR can't touch. So I'm debating whether or not I fork the archive, and use EXIFtool to create dupe files *with* the metadata, while leaving the originals alone. Use EXIFtool to move the updated files to a new scanable archive, then let LR grab hold of those dupes. So I can search the tiffs and JPGs, and if I really need the rest of the package, I can go back and pull it from the morgue.

I'm using LR more like a DAM package than any sort of manipulation program. I like how it handles keywords & etc far better than Bridge, with the glaring exception of fouling up the file dates.

-Brian

Champion

 • 

5.3K Messages

 • 

95.7K Points

Thanks, that could help others in the future.

21 Messages

 • 

300 Points

5 years ago

Damn, it really hates that script. Think I know why.
In the following, replace "@" with the less than symbol (left pointing pointy parens.)
That should get it thru.
-B

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

exiftool -r -delete_original .

Champion

 • 

2.6K Messages

 • 

33.7K Points

5 years ago

The messages on this forum allow some HTML which oftentimes are enclosed in < and > signs.

Champion

 • 

2.6K Messages

 • 

33.7K Points

So instead of using the less-than and greater-than signs use < and >

444 Messages

 • 

6.6K Points

5 years ago

There is a plugin for LR that allows you to copy capture times from LR into Exif in your images.

http://www.photographers-toolbox.com/...

Bob Frost

2 Messages

 • 

70 Points

5 years ago

Just discovered today that photos I have renamed using LR 5 have new Crested Dates, and the Modified Date matches.

That is a HUGE problem with my nearly 100,000 photos I trusted to Adobe.

There is no reason whatsoever to change the creation date when changing a name of a file. Period.

Now my library is hosed. I can no longer find files by the dates I knew I shot them.

It's irritating, too, to read through this set of posts and see all the pompous responses, from questionably-authoritative "this is what Adobe safely does" to the missing-the-point suggestions on how to fix, to the "missing the point" pontifications on "here's how I always do it form the beginning."

The POINT is that Adobe really screwed up with the mac Version and they still have not fixed it.

My trust of Adobe has severely diminished. Forcing "subscriptions" to software I formerly licensed at a very high cost was the first nail. This may be the last, Adobe.

Sadly, Apple is following their lead and taking Photo apps back to the stone age.

I'm so, so upset by this. I can no longer recommend Adobe products.

21 Messages

 • 

300 Points

Yes. Thus my annoyance earlier in the thread. Fortunately, I figured it out before I screwed up any files I couldn't get back from CD, but yeah. You are not alone.

As far as the subscription model goes: no bloody way. I'll stick with CS6 until Apple does something that breaks it for good. (And given the bad blood between Apple and Adobe, I don't think they're likely to do that anytime soon.)
All of the prepress people I know are staying with CS6 for the foreseeable future.
All in all, not a good couple of years for Adobe.
Seems they forgot *why* we all jumped ship from Quark as soon as ID got good enough: Quark had spent *years* taking us for granted, and treating us like cash cows. Sound familiar?

-Brian

444 Messages

 • 

6.6K Points

Another pompous reply - just go back to the backups of your 100,000 images before you renamed them. They will still have the dates you want presumably. But for goodness sake if you've been relying on the filesystem dates, get them into exif/iptc or into the filename asap. I've just done both with my 90,000 images - belt and braces. Now the images sort the same, whether they are sorted by filename or capture date. Filesystem 'create' dates are NOT reliable.

Bob Frost

67 Messages

 • 

950 Points

Exactly. That's exactly my point of view. I will cancel the subscription for this bug.

444 Messages

 • 

6.6K Points

Reinard, I think you've got it wrong. The filesystem 'create', 'modified', and 'accessed' dates were designed for the filesystem of your OS, whether Mac or Windows, to keep track of all your files, program files as well as image files. They were NOT designed to record the date on which you took your photos. The Exif 'capture', 'digitised', and 'modified' dates were designed specifically for this purpose, for us as photographers to use, and are stored in our images files, not in the filesystem.

So why try and use the filesystem dates when we have our own specifically designed dates in the actual image files?

As for blaming Adobe, Adobe is so scared of altering your image dates, that is only allows you to alter 'capture' dates in raw files, after you have given them special permission to do so, in your prefs.

So don't rely on filesystem dates that have always been flaky, and probably always will be, and that can be altered by the OS and programs without you knowing.

Bob Frost

67 Messages

 • 

950 Points

I am absolutely right. Completely. Adobe is not allowed to touch the creation date as I wrote for several times in these posts. It's a bug they have to correct. They don't have it in other products. Creation date is exactly a file related system item which must not be changed by anybody; the file was created at that date. Once and for ever. Period. Why we should have a OS that is looking for these dates when any buggy software changes it? First point.

Second point, I repeat this again: The EXIF dates are unusable if you need a timeline of you photos in Finder. This is absolutely necessary if you are travelling and have hundreds of pictures every day of several cameras. How you ever would be able to sort them in a time line???

That's why I copy the EXIF date from every photo to creation date from time to time to correct buggy software which changed creation date mistakenly. BTW: »A Better Finder Attributes 5« doest this job perfectly.

For me LR seemed to be a good software to manage my about 200.000 photos. But it isn't. That's why I have canceled my subscription to CC. The older PS and LR are still good enough, other SW not mentioned.

444 Messages

 • 

6.6K Points

5 years ago

Second point, I repeat this again: The EXIF dates are unusable if you need a timeline of you photos in Finder. This is absolutely necessary if you are travelling and have hundreds of pictures every day of several cameras. How you ever would be able to sort them in a time line???
.......................

I don't use Macs, but I take thousands of pictures on two or three cameras while travelling, and provided I have remembered to sync the date-time on the cameras before I go, I have no problems sorting them by capture date/time in exif. The only problem is if I am taking several images per second. Then those can get sorted by camera internal file name, if necessary.

Creation date is exactly a file related system item which must not be changed by anybody; the file was created at that date. Once and for ever. Period.
..................................................

The filesystem creation date is NOT permanent; at least not in Windows. It is a file creation date, so if you copy a file, the copy will have a new creation date - the date on which the copy was created. Quite logical. Then the file system can distinguish between the copy and the original. It doesn't usually change when you rename a file, but loads of programs and utilities can change these filesystem dates. They are not immutable. The exif dates are much more reliable, and are in the actual files, wherever you move them or copy them.

Why do you think Exif dates were created? To avoid the problems with filesystem dates and create permanent records of the capture, digitised, and modified dates for us photographers.

Bob Frost

67 Messages

 • 

950 Points

To use EXIF date for sorting it's necessary to use a tool. In the finder it is not applicable. So to copy the exif date to creation date is the best way for me - if there is one. So I created it in old photos first. ExifTools helps a lot. So in the end I can go without LR...

21 Messages

 • 

300 Points

5 years ago

Robert, please follow along:

A) we've been talking about Mac file systems. Windows behaviors are cute, but irrelevant here.

B) at least in my case, (don't know about the others) I'm using LR to keep track of images that either predate metadata, never had any to begin with, or were generated by Photoshop/god-knows-what, and never had any metadata from any sort of camera, because they weren't photos. Even my Nikon film scanner didn't do metadata, back in the day.
I've got drum scans of Apollo negs straight from NASA that don't have any metadata in them.

So the 'why use the file date?" question has been answered over and over again: because we have no choice. Kibbitzing about it being a bad idea doesn't help.
If I'd *known* that, 25 years ago, I might have set up a different system. But I didn't. So now I'm stuck with making the archive I do have work.

For me, this isn't about photography, it's image archive management. I can't change the file names, and I have to depend on the file origination dates being good, at least until I can use EXIFtool to load them into the (newly generated) metadata, where they're still searchable, and less likely to get screwed up by sloppy coding.

For people following along this thread later, follow back thru, and I've got a method using EXIFtool to load the creation dates into the metadata that should be of use to you.

-Brian

18 Messages

 • 

310 Points

5 years ago

A latecomer here as I just learnt about it from another forum where I raised the same problems but haven't yet quite found out why and how to solve it.

I'm using Lightroom 5.7.1. on a Mac with OSX 10.9.5. and have organized my photos in such a way that they can just as well be found in the OSX Finder and not just LR, which is why Creation dates are just as important as the EXIF dates to me. Much to my shock I found out that over 2000 of my photos had their Creation dates changed, and I've since tried to figure out why and how to prevent this from happening again (fortunately I have backups, but it's going to take forever to restore them, given all the different locations they're in).

So there's a lot of disagreement on why this is happening, and if it's a bug or feature.
I read earlier in this thread where Steve Sprengel says the purpose of all this is to have LR write a temporary file while adding the keywords, then creating a new file with those keywords. Well, that doesn't explain why Adobe in their wisdom didn't put in a couple of extra lines of code to overwrite the new file's Creation date with the original Creation date as should be (after all, the file, as seen from the user's point of view, hasn't been re-created, just had some new information added to it -so this should essentially just leave a changed Modification date).

To me all this is definitely a bug because IMHO no software should tamper with the date a file was created without alerting the user at least, no matter what. My tests indicate that many of the files can be fixed by using "A Better Finder Attributes" with the "Copy EXIF to Creation date" setting, but once I add/change the keywords for those files again in LR the date is yet again updated to now.
I could probably decide never to change the keywords ever again, run the above software to fix the date, then lock all those files in OSX' Finder, or just avoid saving the EXIF data (CMD-S) in LR (I suppose this keeps the keywords etc. within the LR catalog and not in the files themselves).

Someone told me the problem appears whenever you have a photo in LR which doesn't have all the usual EXIF time/date tags, such as a scanned image or old digital camera, but this surely isn't it because I just imported several Canon G7X shots today and the JPG files got their dates changed (I usually shoot RAW but some JPGs were generated when I set the camera to a different mode it seems).

Has this problem been fixed in LR 6? Has Adobe responded to this bug report at all or are they just pretending it's not there or a nice feature (for some unknown purpose)?

Champion

 • 

5.3K Messages

 • 

95.7K Points

If you decide to continue relying on the file date created as the "truth", beware that a significant minority of Mac apps other than LR don't preserve it, and most cloud services won't either. So before using any new app, utility, script, network drive, service, etc., carefully test it to make sure it preserves date created.

Regardless of whether Adobe eventually fixes LR to follow the convention (as Photoshop and Bridge do), I highly recommend that you transition to storing capture time in the photo industry-standard XMP and EXIF metadata. Nearly all photo apps and Web services implement those standards and is the best way of preserving your date/times for the long term.

Then, if you want to use Finder for browsing, use one of the methods described in this thread: use a utility or plugin for copying the metadata capture time back to date created, or rename your files to include the original capture date.