P: XMP:MetadataDate has wrong time zone

I have discovered that the problem could possibly be related to using a large capacity memory card. Some of the images from a large shoot have the correct date, a portion do not. Several photos were disqualified from a date sensitive competition. Although all the submitted photos were shot on the applicable date, several rogue shots showed the following day's date. Have you heard of this problem in relation perhaps to a memory card? It has been reformatted?

Rosalie,

If you include an original image that shows this problem, some of us might be able to help troubleshoot the problem. You can include the image directly using the photo icon at the bottom of the reply box, or you can use a free service like pixentral.com or Dropbox.com.

You can correct in bulk using Edit Capture Time on the Metadata menu in the Library module. But that's small consolation if you use the date/time in folder/file naming, or if you have to do it every time, or remember to check...

For me its even worse - sometimes it imports with the correct date, and sometimes not.

My solution: RC Importer - its not for everyone, but at least it always gets the date/time correct.

Problem importing photos to Lightroom from Canon 5D Mark 11 (plus Mark 1). Lightroom imports with tomorrow's date, cameras are set correctly as is PC. Disqualified from competitions because of this (photos appeared to be shot after closing date) . Please help.

Thanks for the update. Does LR ever read that field, or is it write only from LR's perspective? Just wondering if it's a possible cause of the "Metadata needs to updated" notifications that have been reported (see the forum thread above).

I have reproduced and logged this bug. The wrong sign is used for the UTC offset. In my investigation so far, it only affects the MetadataDate tag, and only occurs on Windows, not Mac, and only in Lightroom and not in other Photoshop Family products.

Here's how I've replicated the problem:

1. Configuration: LR 3.4, Windows 7 Professional 64-bit

2. Verify clock set to UTC-8 (see screenshot below).

3. Make a new catalog.

4. Remove all metadata from p.jpg (attached below) with:

exiftool -all:all= p.jpg

5. Import p.jpg.

6. Add a caption in the Metadata pane.

7. Metadata > Save Metadata To File

8. Examine the metadata with Photoshop Elements 8 File > Info, and on the Advanced tab see xmp:MetadataDate containing a "+7:00" rather than "-7:00":

2011-05-14T07:30:44.017+07:00

8. Examine the metadata with exiftool and observe that XMP:MetadataDate has a "+7:00" rather than "-7:00":

C:\Users\Ellis\Desktop\test pics>exiftool -a -G -s p.jpg
[ExifTool] ExifToolVersion : 8.25
[File] FileName : p.jpg
[File] Directory : .
[File] FileSize : 987 kB
[File] FileModifyDate : 2011:05:14 07:30:44-07:00
[File] FilePermissions : rw-rw-rw-
[File] FileType : JPEG
[File] MIMEType : image/jpeg
[File] ExifByteOrder : Big-endian (Motorola, MM)
[File] CurrentIPTCDigest : 08e4c683387bba4d1884d4f0729495
c1
[File] ImageWidth : 2560
[File] ImageHeight : 1920
[File] EncodingProcess : Baseline DCT, Huffman coding
[File] BitsPerSample : 8
[File] ColorComponents : 3
[File] YCbCrSubSampling : YCbCr4:2:2 (2 1)
[EXIF] ImageDescription : Caption for p.jpg
[EXIF] Orientation : Horizontal (normal)
[EXIF] ExifVersion : 0221
[XMP] XMPToolkit : Adobe XMP Core 5.2-c004 1.1368
81, 2010/06/10-18:11:35
[XMP] MetadataDate : 2011:05:14 07:30:44.017+07:00
[XMP] RawFileName : p.jpg
[XMP] Description : Caption for p.jpg
[IPTC] CodedCharacterSet : UTF8
[IPTC] ApplicationRecordVersion : 4
[IPTC] Caption-Abstract : Caption for p.jpg
[Photoshop] IPTCDigest : 08e4c683387bba4d1884d4f0729495
c1
[Composite] ImageSize : 2560x1920

Image is not available

Image is not available

No, that is literally what it says in the metadata of my file (two zeros inside two question marks). I think that's (blank) sub-second info, but I'm not positive.

The EXIF spec doesn't allow for timezones, but I've seen some files that have them stuffed in anyway. Your notes above say "The DateTimeOriginal is ..." with some stuff that doesn't map to ASCII properly but appears to be long enough to include a timezone, which is what made me think of it.