Time zone offset at IPTC:TimeCreated/IPTC:DigitalCreationTime

[Joel23]

Hi Phil,
I am pretty new here, but for almost a decade an ExifTool / IMatch user.

While beta-testing IMatch V5 (which strongly relies on ExifTool) and working with Exiftool outside of IMatch, I noticed that ExifTool always assume and apply computer's time zone offset for the mentioned IPTC date/times, even when "-use MWG" is used.
Which give's strange effects, especially when traveling and editing images in different time zones. While in KL we get UTC+08:00, in Alaska UTC-08:00 and in Germany UTC+01:00. And again get a different offsets when we edit the same images here in Germany when DST is effective (UTC+02:00) See attachments.

Aside that it makes not much sense when different time zone offsets for IPTC date/times all the time are added, it might produce problems for tags which relates on it and, per MWG compliance guide (see page 33-34, Time-zone handling), a time zone offset never should MUST implicitly assumed/added when it is unknown:

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

[Phil Harvey]

Hi Joerg,

The IPTC time specification includes a time zone, so this data should exist in the file.  Use the -v3 option to see the raw data stored in the file.  ExifTool does not add a time zone to IPTC times.

As well, ExifTool does not add time zones to EXIF or XMP information.

So I'm afraid that I don't know what you are talking about.

- Phil

[Joel23]

Hi Joerg,

The IPTC time specification includes a time zone, so this data should exist in the file.  Use the -v3 option to see the raw data stored in the file.  ExifTool does not add a time zone to IPTC times.

As well, ExifTool does not add time zones to EXIF or XMP information.

So I'm afraid that I don't know what you are talking about.

- Phil

Hi Phil,
I am afraid, it does this since ~ V6.4. I proved that 100 times now. Must be hard-coded in exiftool.exe and in the perl version
Since its easy to check by changing computers time zone to something different and launching Exiftool with -iptc:timecreated=10:00:00, did you?

You might have forgotten about this:

IPTC time values include a timezone offset. If written with a value which doesn't include a timezone then the current local timezone offset is used (unless written with a combined date/time, in which case the local timezone offset at the specified date/time is used, which may be different due to changes in daylight savings time).

June 9, 2010 - Version 8.22
Assume local system timezone on specified date (instead of current local timezone) when writing an IPTC time tag with a date/time value which doesn't include a timezone

I don't get this: what is the difference in "local system timezone" and "current local timezone" ? Is this referring to DST?

I downloaded Exiftool V6.36: it only adds +00:00 to IPTC:TimeCreated as it IMHO should be and for example Photoshop and RawTherapy does because it does not makes much sense to add the time zone to IPTC, in which a file was edited/saved.

As well, ExifTool does not add time zones to EXIF or XMP information.

Allow another question about the arg files which come with the tar-ball: are they examples or meant for regular use?
'cause the added time zone offset for IPTC:TimeCreated will be spread to other tags by the arg file

For example to -XMP-photoshop:DateCreated via Composite:DateTimeCreated by iptc2xmp.args and from there back to -EXIF:DateTimeOriginal and -IPTC:TimeCreated via XMP-photoshop:DateCreated in xmp2exif and xmp2iptc.args.
Of course adding a time zone does not work on native EXIF tags.

[Phil Harvey]

Since its easy to check by changing computers time zone to something different and launching Exiftool with -iptc:timecreated=10:00:00, did you?

Oh.  You're talking about writing.  Sorry, I thought you were saying that ExifTool was adding a time zone when extracting information.

As I said, the time zone is stored in IPTC time tags, so if you don't specify one then ExifTool will make (in my opinion) the most reasonable assumption.  If this assumption is wrong, then it is up to you to specify the correct timezone when setting the value.

- Phil