Hi Phil, I've noticed lately that going back to around last mid December any time I use -TagsFromFile to copy all metadata from DNGs to JPGs, there are one too many characters at the end of the EXIF last modified timestamp of the JPGs. The seconds always have a Z appended at the end. I'm using the Windows executable version 7.13. Many thanks for all you do! John

Thanks for the response Bogdan. I am seeing a Z appended to the end of the timestamp however this is the EXIF last modified date/time tags which I didn't think supported time zone information. When I look at the xmp last modified timestamps I do see the timezone trailing the rest of the timestamp just as you say.

This started happening in mid December which is also when the latest Lightroom was released. So I'm not so sure I'm in the right forum here, but I need to start somewhere. :)

Just to be clear on my workflow:
1. I shoot Canon raw CR2
2. In Lightroom I cull and export the better images as DNGs without any metadata.
3. Then I use ExifTool -TagsFromFile To copy all tags from the CR2 originals to the appropriate DNGs.
4. The DNGs are further rated/culled/optimized and finally exported as JPGs, again without any metadata.
5. And last I use ExifTool -TagsFromFile To copy all tags from the DNGs to the appropriate JPGs and that is when the Z is appended to the end of the EXIF last modified timestamp of the JPGs.


Thanks again.

John

I just realized that you can not avoid the XMP date/time parsing with the -n option as I implied in my previous post. This does work for EXIF, but the XMP formatting is currently a bit more restrictive and doesn't allow invalid date/time values like this to be written.

- Phil

Hi John,

There is no EXIF "last modified" tag. Are you talking about EXIF:ModifyDate? Did you use -G1 to be sure the information is in the EXIF? (Also you may want to use -s to get the exact tag name.) I was assuming that it was XMP because the EXIF doesn't contain timezones, and in fact exiftool will strip them off if the exist when writing unless the -n option is used.

- Phil

Hi John,

Thanks for additional explanation -now I can confirm, it happens here too. In my case, instead of trailing "Z", I get trailing "+01:00".
That is, this happens only if source file is DNG -is this because DNG also has ModifyDate inside XMP?

Bogdan

Hi Phil,

Could be, I mis something, but I would expect, that (for DNG, which contain both, exif and xmp):

exiftool -tagsfromfile src.dng dst.mie
and
exiftool -tagsfromfile src.dng -all:all dst.mie

-would give identical resulting mie file.
Right now, if -tagsfromfile is used without "-all:all", resulting EXIF:ModifyDate has trailing TimeZone (but resulting EXIF:DateTimeOriginal and EXIF:CreateDate doesn't have it).
And if I include "-all:all", then none of resulting EXIF DateTimes has trailing TimeZone.

I'm thinking... As far I have tested, traling TimeZone appears only if:
1. "-tagsfromfile" is used,
2. it's without additional (-all:all) option,
3. it appears only for EXIF:ModifyDate.
-in all other cases (AFAIK), there's no trailing TimeZone result for any of EXIF DateTimes.

This would suggest to strip TimeZone for EXIF:ModifyDate in this case too -especially if source EXIF DateTimes doesn't contain TimeZone trailings. Btw. somehow I have a feeling that resulting EXIF:ModifyDate is copied from XMP:ModifyDate, while other two DateTime values are copied (as expected) from EXIF -that's the only explanation for "from where is trailing TimeZone data comming?".
It's about consistency: when copying metadata, either none of EXIF DateTimes has TimeZone trailing (which I prefer), or all have it (but that's not what most users would expect, though). Even better: resulting EXIF DateTimes should have the same format as source file (when using "-tagsfromfile").
Anyway, as it is, it can be confusing... I'm not saying what you should do -I'm only thinking loud :-)

Greetings,
Bogdan

Thank you for clarifying some things... and I hope you don't find I'm "pushing" too much :-)

As far I can tell, using "-all:all" behaves as expected and I always specify what to read/write when using ExifTool (despite missing two DateTimes, which will be corrected in v7.15, you said).
It is just how EXIF DateTimes are written (using -tagsfromfile) when tag/group isn't specified: EXIF:ModifyDate has TimeZone, while EXIF:DateTimeOriginal and EXIF:CreateDate haven't. But, speaking for me (as I always specify Group/TagName), it really doesn't bother me.

I realy don't know if there's something "needed" to be changed. Despite above "issue", ExifTool (at least how I use it) always does as expected:
1. EXIF DateTimes written or copied from somewhere, never have TimeZone trailers,
2. XMP DateTimes written or copied from somewhere, always have TimeZone (or "Z" if there's none)
IMO, that's how it should be. And I see "-n" option as a feature when writing DateTimes -to override default DateTime format.
So, as long ExifTool does as said above (1. and 2.), I wouldn't change nothing in this regard.

Thank you for patience,
Bogdan

Hi Phil,

I just wanted to report the latest build seems to have cured my EXIF problems from before. Many thanks!

John

Yes. When extracting information, you will see what was stored in the image. Typically only XMP tags will have timezone information (use the -G1 option to see where the information came from).

We were talking about what happens when you write new information, in which case the timezone is added automatically to XMP date/time values unless already specified.

- Phil