Skip to main content
Adobe Photoshop Family

27 Messages

 • 

1.3K Points

Wed, May 11, 2011 8:12 PM

Solved

Lightroom: "Data/Time digital" not shown correctly in Lr 3.4

I recently noted that in Lr 3.4 the metadata field "Date/time digital" does not show the correct date any more. It always shows the date/time of the other two date/time fields.
I've tested my catalog again with Lr 3.3 and there it shows correctly. This seems to be bug introduced in Lr 3.4.

Responses

Official Solution

Adobe Administrator

 • 

14.7K Messages

 • 

283.8K Points

9 years ago

The final release of Lightroom 3.5 fixes this issue. Launch Lightroom and choose Help>Check for Updates... to install the update.

Sr. Product Manager, Adobe Digital Imaging

Champion

 • 

5K Messages

 • 

91.8K Points

9 years ago

I assume you're referring to Date/Time Digitized in the Metadataq panel? Can you include a sample image that illustrates this, along with what you see in the Metadata panel in 3.3 and 3.4? LR 3.4 has changed its handling of metadata in some ways to conform with a newer standard, and I'm wondering if you're seeing the effects of this. Posting a sample image will help clarify that.

142 Messages

 • 

3.7K Points

9 years ago

Right, 3.4 follows the latest Metadata Working Group guidance, which says:
If both XMP (xmp:CreateDate) and Exif DateTimeOriginal are missing, but Exif DateTimeDigitized (36868, 0x9004) exists, Exif DateTimeDigitized SHOULD be used to create an initial XMP (xmp:CreateDate). This is also true in the case that only IPTC DateCreated is available.

That's the only scenario I see where the behavior might have changed. But as John says, seeing the original file (so the metadata can be inspected) would be really helpful.

27 Messages

 • 

1.3K Points

9 years ago

Yes, I refer to the Date/Time Digitized in the Metadata panel (sorry for the incorrect translation - I'm using Lr in German :-). This happens with my slide scans. What I've done is I changed the capture date/time using Lr's "Edit capture time" (or similar) command in the Metadata menu to change the date to the original capture date and the time to 00:00:00 (because I don't know it).
See below how the dates are shown using the identical catalog in both Lr 3.3 and 3.4.
("Ursp. Dat./Uhrz." means "Original Date/Time"). In Lr 3.4 the digitized data does not appear correctly.


I will post the corresponding TIF image tomorrow as I don't have it at hand just know.
Hope that helps.

Champion

 • 

5K Messages

 • 

91.8K Points

9 years ago

I just reviewed my catalog of scanned images. Looking at images that were imported and had their capture date/time changed using LR 3.3, some have the metadata field XMP:CreateDate set to the scan date (correct), and some have it set to the same value as XMP:DateTimeOriginal (the capture time, which is incorrect). LR 3.4 is displaying the value of XMP:CreateDate in the "Date Time Digitized" field of the Metadata panel.

I can tell from the metadata that there was a different workflow involved for the two sets of images, but I'm not sure as to the details. There's pretty clearly a bug somewhere.

As soon as you post a problem image, we might learn more about what's happening in your catalog.

Adobe Administrator

 • 

14.7K Messages

 • 

283.8K Points

Hi John, is the issue you just posted http://feedback.photoshop.com/photosh... related to this topic?

Sr. Product Manager, Adobe Digital Imaging

Champion

 • 

5K Messages

 • 

91.8K Points

I don't think they're necessarily related. I just happened to notice the XMP:MetadataDate time zone issue when I was looking at metadata for this topic, and I remembered that others had noticed the same thing, so I wanted to get it recorded. But I don't see offhand any relationship between the two topics.

Adobe Administrator

 • 

14.7K Messages

 • 

283.8K Points

Thanks. I've asked someone from the Lightroom eng team to review both topics.

Sr. Product Manager, Adobe Digital Imaging

27 Messages

 • 

1.3K Points

9 years ago

Hi, since the TIF test file is about 25 MB and I did not want to change it in any way in order to keep it as it was imported in Lr, I've uploaded it on a web-drive:
Here is the access (which I keep live for a week):
http://www.mydrive.ch/login
user: test@bonnies
password: testlr3

Hope that helps - and I hope that I will get back my information as it used to be in Lr3.3.
Thanks
Sven

142 Messages

 • 

3.7K Points

9 years ago

Here are the relevant metadata fields, as reported by exiftool v8.5.6 using "-a -G0:1 -s":

[EXIF:IFD0] ModifyDate : 2009:03:13 15:21:10
[EXIF:ExifIFD] CreateDate : 2009:03:13 15:21:10

These are the exiftool names for EXIF DateTime and DateTimeDigitized.

So where is the 1988 date coming from? Is this something you did in Lightroom after Import? It doesn't show up in the original.

27 Messages

 • 

1.3K Points

9 years ago

Yes, Mark, what I've done is I changed the capture date/time using Lr's "Edit capture time" (or similar) command in the Metadata menu to change the date to the original capture date and the time to 00:00:00 (because I don't know it).
Maybe I should add that I did not export the changed metadata from Lr to the TIF file - hence the TIF file is still the original one.

142 Messages

 • 

3.7K Points

9 years ago

Thanks for the explanation. This appears to be a bug to me -- when you change the capture time to a specified date and time, it changes every date it's got. It probably shouldn't change DateTimeDigitized.

MWG guidance allows for separate concepts of "Original Date" and "Digitized Date". It does not suggest that they be mapped together, but that appears to be what LR3.4 is doing. I think this is a bug in the new metadata model.

Changing the date in Lightroom should only affect the "Original Date", not the "Digitized Date", IMHO. I could see people also wanting to change the latter, so perhaps that's worth a feature request, but I feel that the current behavior is a bug.

Champion

 • 

5K Messages

 • 

91.8K Points

9 years ago

The issues discussed here are some symptoms of more extensive problems with LR 3.4's handling of metadata dates. See my problem submission:

http://feedback.photoshop.com/photosh...

474 Messages

 • 

10.7K Points

9 years ago

Thanks Sven, I've reported this bug to the Lightroom engineers.

-Ben

27 Messages

 • 

1.3K Points

9 years ago

Thanks Ben

111 Messages

 • 

2.3K Points

9 years ago

Changing both the DateTimeDigitized and DateTimeCreated is the right thing to do for a digital still capture. With a digital camera, the image is of course digitized at exactly the same time it's created. Adding better support to Lightroom for files that are scans from film, or digital photos of other original artwork, seems like a reasonable feature request.

Champion

 • 

5K Messages

 • 

91.8K Points

9 years ago

> Changing both the DateTimeDigitized and DateTimeCreated is the right thing to do for a digital still capture. With a digital camera, the image is of course digitized at exactly the same time it's created.

Agreed, that makes sense for digital camera stills (LR's main focus).

But this was an undocumented change from LR 3.3 and earlier, so for those of us with scans, it can cause Date Time Digitized to be overwritten and lost.

I'd prefer the old behavior for Edit Capture Time: For digital camera stills, Date Time Original is what people care about, and they don't pay attention to Date Time Digitized or care that when they need to change Date Time Original because their camera clock was set wrong, Date Time Digitized isn't getting changed also. But for scan-based workflows, Date Time Digitized can be very important, and changing it when you change capture time loses data.

27 Messages

 • 

1.3K Points

9 years ago

I agree with John.
It scared me when I realized that all of a sudden (when updating from Lr 3.3 to 3.4) all of my scans don't show the correct "date/time digitized" any more but only the same date/time in all the 3 date/time metadata fields.
I've reinstalled Lr 3.3 in order to work with access to the correct date/time and without loosing data, and I surely hope this to be fixed in the next update of Lr.