• Welcome to the Lightroom Queen Forums! We're a friendly bunch, so please feel free to register and join in the conversation. If you're not familiar with forums, you'll find step by step instructions on how to post your first thread under Help at the bottom of the page. You're also welcome to download our free Lightroom Quick Start eBooks and explore our other FAQ resources.
  • Stop struggling with Lightroom! There's no need to spend hours hunting for the answers to your Lightroom Classic questions. All the information you need is in Adobe Lightroom Classic - The Missing FAQ!

    To help you get started, there's a series of easy tutorials to guide you through a simple workflow. As you grow in confidence, the book switches to a conversational FAQ format, so you can quickly find answers to advanced questions. And better still, the eBooks are updated for every release, so it's always up to date.
  • 21 February 2024 It's Lightroom update time again! See What’s New in Lightroom Classic 13.2, Mobile & Desktop (February 2024)? for all the update news. It's mainly new cameras, new lenses and loads of bug fixes in this release.

Creation date and export & import question

jon.a.blackman

Member
Premium Classic Member
Joined
Feb 22, 2021
Messages
37
Lightroom Version Number
12.5.1
Operating System
  1. macOS 11 Big Sur
What am I missing?

I have a photo with a capture date/time of October 3, 2023 at 8:11:00 AM
After exporting to my Mac, I see with the Inspector "Created: November 24, 2023 at 1:23 PM" and Modified: November 24, 2023 at 1:23 PM"
I import it to Apple Photos, and the time is listed as October 3, 2023 at 8:11:00 AM
I am ok with this behavior, as it does what I want, placing the photo chronologically. I assumed it was normal mapping behavior.

Now I create a Collection in LRC and view it on the web.
I export the photo to my Mac, and again the Created and Modified date is November 24 at 11:23 PM.
I import it to Apple Photos and the time is listed as November 24, 2023 at 11:23 PM
This now places the imported photo as the newest photo, completely out of chronological order.

I am creating the Collection to share with a travel group, and most will want to import my photos into Apple Photos, but this behavior makes it very difficult to view my photos chronologically alongside their own photos and plays havoc with their Apple Photos library.

Any thoughts/suggestions? As I have noted recently, my system is falling behind (LRC 12.5.1 and MacOS Big Sur 11.7.10), but I doubt this is the issue.
 
Let me add two additional data points
  • All LRC photos and all Collections are ordered by Creation Date (which is also the Apple Photos default).
  • The Creation Date is correctly displayed in the Collection photo on the web (using the built-in Inspector)
My guess is that LRC preserves the Creation Date on export and that web-based Collections strip off this information on export (probably by design).

I don't see any solution other than downloading the Collection files on my Mac using LRC and physically sending them to others on a USB drive, using Dropbox, etc. . I assume that these would import into Apple Photos correctly. Or the user could download all files, import to Apple Photos, create an Album and use this to add their own photos, manually moving them as desired.
 
the Mac is showing the date/time that the FILE was created. IIRC, ther are about 5 date time fields stored in the header. Since Apple Photos is aware that this is a photo, it correctly show the date time shot which is one of the other fields in the file header.


Sent from my iPad using Tapatalk

In finder you can show columns for the other date time fields in the file header.
 
Thanks. I understand that there are multiple date/time fields.

It turns out that if you "download all" of the Collection from the web page on a Mac, it preserves the creation date and sorts files chronologically in Photos.

If you "download all" to Dropbox or Files from an iPhone or iPad, and then add the files to Photos on your Mac, it does not preserve the creation date, and photos are added to the end of the Photos library.

Also, if you download a single photo, it does not preserve the creation date.

Not very consistent , and I think this qualifies as a bug as the behavior is inconsistent. And very frustrating.
 
If you "download all" to Dropbox or Files from an iPhone or iPad, and then add the files to Photos on your Mac, it does not preserve the creation date, and photos are added to the end of the Photos library.
How exactly are you doing this "download all to Dropbox or Files" from your iPhone/iPad, i.e. what app are you using (presumably Lightroom), and what method are you using to do that "download"?
 
Sorry that I did not make myself clear. On a recent trip to Greece, I was the unofficial photographer for the group. I gathered about 1500 photos from my Sony camera, iPhone, and from fellow travelers. I selected 350 photos, edited them, and created a Collection in LRC. I synched these photos, edited the web page and created a link for others to view. My goal was to allow them to view the photos easily, but also to be able to download them and add them to their Apple Photos library.

On a Mac, as the link opens to the Collection home page, there is an option to download all photos. These save on the hard drive in the downloads folder and when imported to Photos, they have the original created date and sort chronologically. This is exactly the behavior that we see when photos are exported from LRC and imported into Photos. So far, so good.

On a Mac, if you select one photo and download it, it is also saved in the downloads folder, but when you import the photo, it has the current created date and sorts at the end of the Photos.

On iOS it gets more complicated. If you open the Collection web page on your iPhone or iPad and you elect to download all photos, you are given a choice of downloading to Dropbox or the Files app. The photos display well within the respective apps and navigation is easy. However, if you decide to import these to Photos (which is complicated), they again sort at the end of Photos with the current date as the created date.

Lastly, if you import a single flle from the Collection web page to your phone, it is also added to the end of the Photos with the current date as the created date.

I do not think there is anything that can be done to change this default behavior of the apps, which took me the entire day yesterday to understand. I will try to explain this to the group members, but I wish it was more consistent. I understand that there are other solutions to share photos, but I want to stay within the LR ecosystem and share my collection. Also, for security reasons, I plan to keep the link live for only a limited time, so users will need to download photos if they would like to view them later.
 
On a Mac, if you select one photo and download it, it is also saved in the downloads folder, but when you import the photo, it has the current created date and sorts at the end of the Photos.

On iOS it gets more complicated. If you open the Collection web page on your iPhone or iPad and you elect to download all photos, you are given a choice of downloading to Dropbox or the Files app. The photos display well within the respective apps and navigation is easy. However, if you decide to import these to Photos (which is complicated), they again sort at the end of Photos with the current date as the created date.
Sort is a function of the viewing app. Some apps only sort by Date added, some by filename. It matters little what date fields are in the fil headers (I suspect most apps dutifully copy the entire file header including all dates provided. The Photos Album give you three sort options. Oldest first, Newest first and custom. Sorting by file name is not even an option. And “Oldest”, “Newest” is Date added not date shot. You may not get what to want using Apple’s Photos apps

A solution that I have used is to create a website using Portfolio. (You can use any other photo sharing website that offers a sort by file name.) Export all of the photos in a custom sorted LrC collection using a Filename prepended by a sequence number to preserve the sequence for a file name sort.


A problem that you have using other people’s cameras is that the date stamp may not be the same across the collection of cameras. On a recent trip to Ireland, I forgot to update my Nikon from CDT to Irish Summer time until two days into the trip. My wife’s iPhone and my iPhone updated automatically. Neither phone was in sync with the other.


Sent from my iPad using Tapatalk
 
I decided to look at some Lightroom cloud shared images. I copied a shared link from a Lightroom cloud album, and pasted it into a Private Browsing window so that it would be viewed in Lightroom Web as a public signed-out user, not signed into my Creative Cloud account. Then I downloaded an album, and also a photo from that album, using Safari on both macOS and iOS.

I then inspected the images using the Exif and XMP tabs in the Information tab in GraphicConverter. Those were completely blank, so I then clicked the ExifTool tab, which displays raw output from ExifTool. I also checked all images using the Metadata panel in Adobe Bridge.

They were all the same (individual photo, album, macOS download, iOS download): Minimal metadata. The downloaded images contain no EXIF metadata whatsoever, regardless of how it was downloaded. The only additional metadata included was Copyright Notice. Everything else was basically OS file system metadata, which of course is the problem; that doesn’t include the original capture date/time.

The only place I can see where to control metadata in a Lightroom cloud shared album is in the Settings tab of the Share & Invite button, and I enabled everything under General, so I guess that’s as much as you can do? Am I missing a switch somewhere that allows more EXIF/IPTC metadata to show up in a Lightroom Cloud download? Because if not, this is disappointing, if there is not an option to include all original and added metadata in a download.

One reason I did that test was to see if Lightroom Web downloads image differently on macOS and iOS, to explain why Apple Photos imported differently for jon.a.blackman on macOS and iOS. It looks like there is no difference. I didn’t continue on to test how the downloaded images import into Photos on both platforms, but if they sort differently on each then it might be a difference between how Apple Photos is coded on macOS and iOS.
 
Thanks for both replies. It appears that there is something happening under the hood that is not apparent, and I will certainly never figure it out.

I am about to send my link to my group. I will tell them that using the MacOS and Importing All will probably give them the best results. However, if photos are not in the desired order, it might be best to create a Photos Album and sort it manually.
 
They were all the same (individual photo, album, macOS download, iOS download): Minimal metadata. The downloaded images contain no EXIF metadata whatsoever, regardless of how it was downloaded. The only additional metadata included was Copyright Notice. Everything else was basically OS file system metadata, which of course is the problem; that doesn’t include the original capture date/time.

The only place I can see where to control metadata in a Lightroom cloud shared album is in the Settings tab of the Share & Invite button, and I enabled everything under General, so I guess that’s as much as you can do? Am I missing a switch somewhere that allows more EXIF/IPTC metadata to show up in a Lightroom Cloud download? Because if not, this is disappointing, if there is not an option to include all original and added metadata in a download.
I can't figure out what might be going wrong in your testing, Conrad. I've been playing with various aspects of album sharing on and off for several years, and in the main I concur with @jon.a.blackman's findings. Specifically, when downloading an album via the public user web interface (and assuming the appropriate options have been enabled in the album's share settings), then all the expected metadata is included in the downloaded files....EXIF, GPS, IPTC and even Keywords are all included. Of course, that data must first be present in the cloud before the download is started. The only "oddity" is the inclusion of Keywords in the downloaded files, because for some bizarre reason the keyword data is excluded when viewing the individual images using the web browser.

Downloading individual files, then discovering that there is no metadata included (irrespective of the album share settings), is another finding that I agree with @jon.a.blackman, but in this case it feels more like a bug, i.e. the web app is defaulting to the basic "no metadata" export for those individual downloads, and ignoring the album share settings.
 
Just a thought. Could the meta-data on the shared link be set at the time the collection link was created?
e.g. @jon.a.blackman enabled the additional meta-data after the link was created. I doubt the collection was altered or updated at that point.
I would not surprise me in the least that the functionality was missed to dynamically adjust what information is placed in the images for download.

Since I am not on my home machine I cannot test it. But a simple test would be to create two shared collections. One with meta-data enabled when creating it, one disabled. Check what is available on download for both. Then alter the settings for each album and check the results.

Tim
 
Ok, this is starting to make sense.

When I look at a file in the Mac Download folder that was downloaded from the LR Collection Home Page using the "Download All" function - using command-shift-p - I can see that the Created Date and the Modified Date are listed as October 1, 2023 (which is the original date).

When I look at the same file in the Download folder that was downloaded by selecting the individual file and using the "Download" function, the Created Date and the Modified Date are both from today.

Also, when I look at the metadata in the Dropbox file on the Mac - that was downloaded initially on the iPad (and shared across all Dropbox folders), it also has the Created Date and Modified Date from today.

Therefore, using the Collection Web Interface
  • Downloading 'all files' on MacOS preserves the Creation Date
  • Downloading 'individual files' on MacOS removes the Creation Date (substituting the current date)
  • Downloading 'all or individual files' on iOS removes the Creation Date (substituting the current date)
Does this seem correct? It seems to explain exactly what I am seeing.

(Tim, your note came in as I was typing this. I can't quite follow the logic, but I did not change anything after the link was enabled.)
 
I would not surprise me in the least that the functionality was missed to dynamically adjust what information is placed in the images for download.
No, it's dynamically updated in the cloud, and the change would be reflected at the client end when the link was next opened (or refreshed if it was already opened).
 
Therefore, using the Collection Web Interface
  • Downloading 'all files' on MacOS preserves the Creation Date
  • Downloading 'individual files' on MacOS removes the Creation Date (substituting the current date)
  • Downloading 'all or individual files' on iOS removes the Creation Date (substituting the current date)
Does this seem correct? It seems to explain exactly what I am seeing.
How are you "downloading" on iOS? In the Lightroom Mobile app there isn't a "download" option (that I can see), there are only the "Share/Export" functions, both of which have their own settings which dictate what metadata is included (similar to the share/export options in the Lightroom Desktop app). There's even a "Save copy to device" option (which saves directly to the Camera Roll/Photos app), and which also has the same settings options. However, if you are using the LrWeb app in a browser (presumably Safari) on the iOS device, be aware that it NOT as functional as the LrWeb app on Mac/Windows systems (though I don't think it even has a download option in iOS)..

If you use the LrM app, and set the share or export settings correctly, you should have no issues in ensuring that the actual capture date is included in the exported files.
 
Well, we are not on the same page...

I am not talking about LR Mobile.

If you are in LRC, you can create a Collection. You can sync it to the cloud, and then create a link to that collection, which can be opened on MacOS or iOS.

If your user opens it on either MacOS or iOS, they can download the photos and import them into their Photos App.

If they use the MacOS and download all the photos, the Creation Date will be preserved. If they use any other option, the Creation Date will be replaced by the current date.

Sorry this has gotten so confusing. I tried to make it clear, but I think I have a working understanding of the behavior...

I appreciate all of the comments.
 
No, we are (sort of) on the same page, you just didn't read my post fully. I was asking how you "downloaded" the album and included "However, if you are using the LrWeb app in a browser (presumably Safari) on the iOS device, be aware that it NOT as functional as the LrWeb app on Mac/Windows systems (though I don't think it even has a download option in iOS)."

So now that you've clarified that that is in fact how you are downloading an album on iOS, I've just tried it on one of my iPads, and ran into problem. I see that a download option is now available (it wasn't the last time I tried this), and the zip file does indeed download. However, I'm not then able to uncompress it at all, as it reports "Inappropriate file type or format". I'll try another device later to see if that works better.
 
I tried a different album on my other iPad, and this worked correctly. On examination, the files contain all the expected metadata (EXIF, GPS, IPTC, Keywords, etc.). The capture date is correct. I saved one of the images to the Photos app, then checked it there, and it still had the correct capture date.
 
Interestingly, I also downloaded a single image from a shared album via Safari on my iPad, and that also included all the expected metadata, so the capture date is correct. Makes it almost certain that the "single image download from shared album on MacOS" behaviour is a bug.
 
Interestingly, I also downloaded a single image from a shared album via Safari on my iPad, and that also included all the expected metadata, so the capture date is correct. Makes it almost certain that the "single image download from shared album on MacOS" behaviour is a bug.

If you guys found a bug, please give the feedback to Adobe.

Tim
 
Jim, great detective work! Additional comments:
  • I have seen the error you mentioning on unzipping the file. I found that if I simply try again, it works.
  • I created a download of all 324 files in my web page with my iPhone. I selected one photo and added it to my Photos app. It displayed at the end of the Library, as if there was not a saved created date. (Not expected.)
  • I opened my iCloud library on my Mac, copied the same file to the desktop, confirmed that the original created date existed, added it to Photos, and it displayed chronologically, as expected. (My head is starting to hurt.)
  • The first time that I downloaded the files on my iPad, i was given the option of saving to Dropbox. Examining those files on Dropbox on my Mac, the original creation date was removed.
  • When I download the files on my iPad now, I do not get the option of saving to Dropbox, as it goes directly to the Files app and syncs with iCloud. I do not know why this is occurring.
There are a lot of moving parts here - Lightroom Collections Web Application export, functionality on Mac vs iOS, import to Apple Photos on iOS and Mac, the relationships to iCloud, the Files folder and Dropbox. I think I have reached the limits of my ability to problem solve this issue, but hopefully this will resolve over time.
 
I can't figure out what might be going wrong in your testing, Conrad. I've been playing with various aspects of album sharing on and off for several years, and in the main I concur with @jon.a.blackman's findings.

After reading the follow-up discussion, I took a closer look and I see that I was looking at things a little differently. I understand the differences now, and should explain a little more about how I looked at it.

Just to clarify, I did not use the mobile apps at all. I wanted to simulate what a non-Adobe user would see, so to download the album or photo, I always used the Download/Download Photos option from the top of the Lightroom web window. I had both my Mac and iPad download them to an iCloud Drive folder, just so I could easily pick them up on the Mac to inspect the photos.

My original reply looked at Exif metadata only, because that is the most reliable way to have other applications see the original capture date/time. But you two were also discussing the file creation/modification dates, which is all Lightroom web gives us, so I went back and looked at those. Re-examining my downloads, I do get the same results that you do:
  • For the individual downloaded photos, the file creation/modification dates are set to the download date/time, matching what you found. Because there is no Exif info, the image contains no record of the original capture date/time.
  • For the downloaded albums, the file creation/modification dates are set to the capture date. This does also match what you found. There is no Exif info, but at least the file creation/modification date is a record of the capture/date time, even if that is not recommended because it’s too easy to change.
I noticed one more weird thing on the Lightroom web downloaded individual images. Although the file creation/modification date matches the capture date, the time does not. Mine are offset by -8 hours. I looked closer, and using RawDigger (to analyze raw/DNG originals) and GraphicConverter (to inspect exports), this is what I found:
  • My original raw files have an Offset Time field which is set to +00:00. I assume this is because I’ve been setting my cameras to UTC, to avoid having to remember to change the time zone when traveling.
  • When Lightroom Classic creates a file, such as an export or a DNG panorama/HDR merge, it modifies that Offset Time to -8:00. I’m guessing it’s because the files are being exported in that time zone, which is 8 hours behind the capture Offset Time of UTC +00:00?
  • When Lightroom web downloads an album, it seems to apply the Lightroom-changed Offset Time to the file creation/modification date/time that it sets for that file. So even if multiple cameras on a trip to Europe were set to the same time, the file creation/modification date/time applied by a Lightroom web download could vary if not all cameras were set to the same time zone, such as some cameras being set to Pacific, Eastern, or Central European.
  • The Offset Time does not change the Exif capture date/time that Lightroom Classic writes into images created using the Export command, and this is correct and accurate. However, because Lightroom web doesn’t include Exif metadata in downloads but instead interprets it before using it to set the file creation/modification date/time, weird stuff happens.
 
Specifically, when downloading an album via the public user web interface (and assuming the appropriate options have been enabled in the album's share settings), then all the expected metadata is included in the downloaded files....EXIF, GPS, IPTC and even Keywords are all included.
The downloaded images contain no EXIF metadata whatsoever, regardless of how it was downloaded. The only additional metadata included was Copyright Notice.
Apart from the file creation date issue, there's still a significant and fundamental difference between what Jim and Conrad are reporting here: "all expected metadata" downloaded, versus "no metadata whatsoever" - what is the explanation for this? My quick testing shows the same result as Conrad, i.e. no metadata is available in the downloaded files.
 
Apart from the file creation date issue, there's still a significant and fundamental difference between what Jim and Conrad are reporting here: "all expected metadata" downloaded, versus "no metadata whatsoever" - what is the explanation for this?

I suspect the explanation may be that some of you are using smart previews synced from LrC, whereas I'm (usually) using original images imported directly into one of the Lightroom apps. I've just tested again with an album that contains a combination of originals and smart previews, and on download only the jpegs derived from the originals contains the EXIF, IPTC data, etc. The jpegs from the smart previews contains only the Copyright. Given that an export of a smart preview directly from Lightroom Desktop DOES contain the expected data, the likely explanation is that different export "types" are used by the album download process in the shared album part of LrWeb, i.e. originals are getting a "Large Jpeg" export including metadata, the smart previews are getting a "Small Jpeg" export but with metadata excluded. Probably another bug.
 
I suspect the explanation may be that some of you are using smart previews synced from LrC, whereas I'm (usually) using original images imported directly into one of the Lightroom apps. I've just tested again with an album that contains a combination of originals and smart previews, and on download only the jpegs derived from the originals contains the EXIF, IPTC data, etc. The jpegs from the smart previews contains only the Copyright. Given that an export of a smart preview directly from Lightroom Desktop DOES contain the expected data, the likely explanation is that different export "types" are used by the album download process in the shared album part of LrWeb, i.e. originals are getting a "Large Jpeg" export including metadata, the smart previews are getting a "Small Jpeg" export but with metadata excluded. Probably another bug.

Is it a bug or a limitation of smart previews? Smart previews are supposed to be small. By default they probably would have stripped everything from them....

Tim
 
Is it a bug or a limitation of smart previews? Smart previews are supposed to be small. By default they probably would have stripped everything from them....

Tim
I don't think it's a limitation of SPs, after all the EXIF data is available when you view the SP in Lightroom Desktop. It just seems that the Album download from the shared album LrWeb interface is not including it....a similar export of an SP from LrD DOES include the EXIF data when using the "Small Jpeg" export preset.
 
Back
Top