Skip to main content
aks100
aks100
Known Participant
July 15, 2024
Question

Daylight saving time, timezone and offset processing in LrC v13.4

  • July 15, 2024
  • 1 reply
  • 626 views

I am reporting an XMP spec error, not a LrC bug, but I can't find a better area to report the issue.

 

An old thread mentioned LrC had no TZ support / didn't recognise offsets in metadata.

 

However, I have noticed that XMP files are created incorporating a TZ adjustment on the end of 'exif:DateTimeOriginal', like this:

  • exif:DateTimeOriginal="2022-09-11T04:28:49.366-05:00"

 

The TZ adjustment in 'OffsetTime' can also include daylight time adjustments too, so one needs to tread carefully. LrC appears to be doing the correct processing from the tests I have done with a Nikon Z6, Canon G7x Mark ii and a Sony Alpha 7 IV. (see attached file for some comparisons).

 

The XMP Spec says:

  • EXIF tags 36867, 0x9003 (primary) and 37521, 0x9291 (subseconds). Date and time when original image was generated, in ISO 8601 format. Includes the EXIF SubSecTimeOriginal data. Note that Exif date-time values have no time zone information.

 

The spec seems to be incorrect and may need to catch up to the actual implementations in LrC v13.4 and Bridge v14.11.1.274. The 'date' format definition does clearly show the details.

 

This topic has been closed for replies.

1 reply

johnrellis
johnrellis
Legend
July 16, 2024

"The 'date' format definition does clearly show the details."

 

While the specification for "date" allows a time-zone designator, it's optional:

 

"The time zone designator need not be present in XMP. When not present, the time zone is unknown, and an XMP processor should not assume anything about the missing time zone."

 

The XMP spec was finalized and became an ISO specification in 2012, I think, while the Exif spec didn't add the time-zone fields OffsetTime* until 2016.  When the XMP spec was written, EXIF didn't allow time zone information to be specified for the DateTime* fields. 

 

But after Adobe wrote the initial XMP spec, they helped form the Metadata Working Group (now defunct), which wrote Guidelines for Handling Image Metadata, which despite its name is really a specification for how photo apps should handle EXIF, IPTC, and XMP metadata. The section "Time-zone handling", starting on page 33, concludes:

 

"In summary, time-zone information MUST NOT be implicitly added and existing values should be preserved."

 

Adobe announced back around LR 3 or 4 that LR would be following the MWG spec. So LR 13 is conforming with the MWG rule for preserving time zone information if present.

 

The XMP spec should probably be updated in this respect, but I doubt that it will be. 

aks100
aks100Author
Known Participant
July 16, 2024

Yeah, I read a lot about the history through posts on this community and other forums, and observing actual behaviours from cameras and photo apps. Made more confusing when the spec lags implementation. Upon reflection, I almost wish Adobe retained the behaviour of the Exif standard, i.e. no TZ on exif:DateTimeOriginal. I say this because, I assume, most people want to use a date/time that reflects the local time the shot was taken which is not then adjusted when they move to a different TZ, e.g. a photo taken at 1pm should always be shown as taken at 1pm, wherever in the world I view. Of course, I know views may differ, and the old thread raised concerns about LrC TZ handling in the past. Maybe an option to disable TZ management 😉 - I suspect even more confusion then!

 

The issue I see here, is that Adobe only added the TZ info to exif:DateTimeOriginal very recently (you mentioned maybe in the last year), and this actually breaks one application I am using - Geosetter.  Geosetter appears to only use DateTimeOriginal from RAW files - which doesn't have a TZ value, and Geosetter doesn't use the separate TZ offset field within RAW files. However, Geosetter does read XMP files. The result is, photos with new XMP files are thrown out of sequence vs photos without XMP files, which makes GPS tracks jump wildly. I will report this to the Geosetter developer too.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices