Inconsistency constructing composite datetime written by exiv2 vs exiftool

[infinity0]

$ x=test1.JPG
$ d="2023-07-21 21:06:26"
$ t="+08:00"
$ exiftool -g -G $x | grep -E -i 'offset.*time|composite.*date'
[EXIF]          Offset Time                     : +08:00
[EXIF]          Offset Time Original            : +08:00
[EXIF]          Offset Time Digitized           : +08:00
[Composite]     Create Date                     : 2023:07:21 21:06:26.8640+08:00
[Composite]     Date/Time Original              : 2023:07:21 21:06:26.8640+08:00
[Composite]     Modify Date                     : 2023:07:21 21:06:26.8640+08:00

Timezone in composite dates.

$ exiftool -P -z -xmptoolkit= -api largefilesupport -overwrite_original_in_place \
  -CreateDate="$d" -ModifyDate="$d" -DateTimeOriginal="$d" \
  -OffsetTime="$t" -OffsetTimeDigitized="$t" -OffsetTimeOriginal="$t" \
  "$x"
Warning: [minor] Maker notes could not be parsed - test1.JPG
    1 image files updated
$ exiftool -g -G $x | grep -E -i 'offset.*time|composite.*date'
[EXIF]          Offset Time                     : +08:00
[EXIF]          Offset Time Original            : +08:00
[EXIF]          Offset Time Digitized           : +08:00
[Composite]     Create Date                     : 2023:07:21 21:06:26.8640+08:00
[Composite]     Date/Time Original              : 2023:07:21 21:06:26.8640+08:00
[Composite]     Modify Date                     : 2023:07:21 21:06:26.8640+08:00

Timezone still in composite dates, after writing with exiftool.

$ exiv2 \
  -M "set Exif.Image.DateTime $d" -M "set Exif.Photo.OffsetTime $t" \
  -M "set Exif.Photo.DateTimeOriginal $d" -M "set Exif.Photo.OffsetTimeOriginal $t" \
  -M "set Exif.Photo.DateTimeDigitized $d" -M "set Exif.Photo.OffsetTimeDigitized $t" \
  "$x"
$ exiftool -g -G $x | grep -E -i 'offset.*time|composite.*date'
[EXIF]          Offset Time                     : +08:00
[EXIF]          Offset Time Original            : +08:00
[EXIF]          Offset Time Digitized           : +08:00
[Composite]     Create Date                     : 2023-07-21 21:06:26.8640
[Composite]     Date/Time Original              : 2023-07-21 21:06:26.8640
[Composite]     Modify Date                     : 2023-07-21 21:06:26.8640

No timezone in composite dates, after writing with exiv2. But the offset is still there.

$ exiftool -P -z -xmptoolkit= -api largefilesupport -overwrite_original_in_place \
  -CreateDate="$d" -ModifyDate="$d" -DateTimeOriginal="$d" \
  -OffsetTime="$t" -OffsetTimeDigitized="$t" -OffsetTimeOriginal="$t" \
  "$x"
Warning: [minor] Maker notes could not be parsed - test1.JPG
    1 image files updated
$ exiftool -g -G $x | grep -E -i 'offset.*time|composite.*date'
[EXIF]          Offset Time                     : +08:00
[EXIF]          Offset Time Original            : +08:00
[EXIF]          Offset Time Digitized           : +08:00
[Composite]     Create Date                     : 2023:07:21 21:06:26.8640+08:00
[Composite]     Date/Time Original              : 2023:07:21 21:06:26.8640+08:00
[Composite]     Modify Date                     : 2023:07:21 21:06:26.8640+08:00

Timezone back in composite dates, after re-writing with exiftool.

[infinity0]

I fat-fingered the original issue submission but have now edited to contain all the details.

Here is a sample input file to run the above commands on, click to expand, copy it as `test1.JPG` in some directory.

I am running exiftool 12.63 and exiv2 0.27.6.

It's unclear 100% if it's exiv2 writing that's the fault, or if it's exiftool reading/constructing the composite values at fault. But I cannot see any difference when examining the written metadata using either exiv2 nor exiftool both in read mode. In any case, it seems that there is some difference that can be distinguished between the metadata written by either tool, and exiftool can use this either intentionally or unintentionally to construct composite datetimes with or without the timezone, which is annoying.

[StarGeekSpaceNerd]

What is rhe output of
exiftool -v3 problemfile.jpg

[infinity0]

The output is very large. I attached an image in the post above, you can run it yourself to have a look.

[infinity0]

The offsets are stored the same in both cases after writing with exiv2 or exiftool, like this:

  | | 7)  OffsetTime = +08:00
  | |     - Tag 0x9010 (7 bytes, string[7]):
  | |         04d0: 2b 30 38 3a 30 30 00                            [+08:00.]
  | | 8)  OffsetTimeOriginal = +08:00
  | |     - Tag 0x9011 (7 bytes, string[7]):
  | |         04d7: 2b 30 38 3a 30 30 00                            [+08:00.]
  | | 9)  OffsetTimeDigitized = +08:00
  | |     - Tag 0x9012 (7 bytes, string[7]):
  | |         04de: 2b 30 38 3a 30 30 00                            [+08:00.]

However the order with respect to other tags is a bit difference. Not sure if that's the cause of this bug. I can't see any other tags that contain the time zone offset.

[boardhead]

Could you post the sample problem file? I don't have exiv2 installed so I can't run that command.

• Phil

[infinity0]

A sample problem file is linked two posts above, click the HTML details element to expand the image.

[infinity0]

This is the file after running the above `exiv2` command on it.

[boardhead]

In the problem file written by Exiv2, the date/times are in the wrong format:

| | 5) DateTimeOriginal = 2023-07-21 21:06:26
| | - Tag 0x9003 (20 bytes, string[20]):
| | 0380: 32 30 32 33 2d 30 37 2d 32 31 20 32 31 3a 30 36 [2023-07-21 21:06]
| | 0390: 3a 32 36 00 [:26.]

EXIF uses colons as date separators, not dashes.

[infinity0]

Ah right, thanks. I guess the "problem" then is that exiv2 doesn't do any conversion from dash to colon, whereas exiftool does. It's easy to miss when checking manually since your eye just expects there to be a dash there. Maybe it would be useful for exiftool to output a warning when it detects incorrectly formatted dates.

[boardhead]

The -validate option gives you this warning:

% exiftool 255207878-1b66909c-5b10-4ffd-b177-202046f4dd8c.JPG -validate -warning -a
Validate : 10 Warnings (5 minor)
Warning : [minor] Invalid date/time format for EXIF:ModifyDate
Warning : [minor] Invalid date/time format for EXIF:DateTimeOriginal
Warning : [minor] Invalid date/time format for EXIF:CreateDate
Warning : [minor] Unrecognized MakerNotes
Warning : [minor] Unknown value for ExifIFD:ColorSpace
Warning : ExifIFD tag 0x9010 OffsetTime requires ExifVersion 0231 or higher
Warning : ExifIFD tag 0x9012 OffsetTimeDigitized requires ExifVersion 0231 or higher
Warning : ExifIFD tag 0x9011 OffsetTimeOriginal requires ExifVersion 0231 or higher
Warning : ExifIFD tag 0xa431 SerialNumber requires ExifVersion 0230 or higher
Warning : Invalid value for ExifIFD tag 0xa001 ColorSpace

[infinity0]

I think it would be better to bump up invalid data to a "normal" or "high" warning severity and show it by default even outside of the validate option.

By default even outside of the validate option, exiftool shows me this:

Warning                         : [minor] Unrecognized MakerNotes

Invalid data that exiftool knows is invalid, is more important than unrecognised or unknown - it means something clearly went wrong somewhere.

Granted, exiv2 doesn't do this either and I'll go file a bug to them as well.

On the specific case of this timezone issue, it's also weird why exiftool decides it's ok to concatenate the subsecond time onto an invalid date, but it's not ok to concatenate the timezone onto it.