Time Zone in Composite Date/Time Original vs -DateTimeOriginal

[ptdotme]

I have some files shot with the wrong time and timezone settings in the camera.

Here is the original "Date/Time Original" in the "---- Composite ----" section:

Code Select Expand

% exiftool -a -u -g1 /path/to/some.CR3  | grep -A 999 'Composite' | grep 'Date/Time Original'
Date/Time Original              : 2025:08:04 04:29:55.59-07:00
% exiftool -dateFormat "%Y:%m:%d %H:%M:%S%z" -DateTimeOriginal /path/to/some.CR3
Date/Time Original              : 2025:08:04 04:29:55-0700
After changing timezone tags to UTC-4h from UTC-7h

Code Select Expand

% exiftool -overwrite_original '-Offset*=-04:00' '-TimeZone=-04:00' '-TimeZoneCity=New York'  /path/to/some.CR3And changing timestamps to add 3 hours

Code Select Expand

% exiftool -overwrite_original -alldates+=3 /path/to/some.CR3
The output time in the "Composite" section looks as expected:

Code Select Expand

% exiftool -a -u -g1 /path/to/some.CR3  | grep -A 999 'Composite' | grep 'Date/Time Original'
Date/Time Original              : 2025:08:04 07:29:55.59-04:00But simply printing the DateTimeOriginal tag shows either the old timezone or my current timezone

Code Select Expand

% exiftool -dateFormat "%Y:%m:%d %H:%M:%S%z" -DateTimeOriginal /path/to/some.CR3
Date/Time Original              : 2025:08:04 07:29:55-0700
I looked for "timezone" in

Code Select Expand

man exiftool but that all appears to be geotag related stuff.  Did I miss some tag when changing timezones?  Or is it using my local timezone somehow?  Thanks.

[StarGeek]

It helps if you use the command in FAQ #3 so all data is available and not hidden as when you use grep. Helpful hint, you can use wildcards (-gps* show all data that starts with "gps") to show certain tags, which won't hide other useful information that might be hidden by grep.

Also, the FAQ #3 command shows tag names, not tag descriptions. In this case, with the -s option you would have seen that the Composite tag is called SubSecDateTimeOriginal, not DateTimeOriginal.

What is the output of this command
exiftool -time:all -G1 -a -s file.cr3

The output from this command will show all date/time related tags. This will help figure out what data you are actually looking at, as your current grepped command deletes a lot of important information, especially from the Composite tag, as the composite tag is made up of three separate tags, two of which will not be shown when you grep like that.

CR3 files are based upon the MP4 format, so some of the time stamps are saved as UTC and exiftool will always convert them to local time when they are displayed.

[ptdotme]

I was using grep to illustrate the discrepancy between the two values.  I assume the rest of the output isn't necessary, but I can paste it here if it'll help.

For my example file, the original timestamp + timezone was wrongly set for the UTC-7 hours timezone:

Code Select Expand

Date/Time Original              : 2025:08:04 04:29:55-0700
(I guess it's worth noting that it actually was ~4:30am here in the Pacific timezone when the photo was taken, but since I was located in the Eastern timezone ideally I'd like it to show the ~7:30am time in the Eastern timezone.)

exiftool will always convert them to local time when they are displayed

After changing the timestamp + timezone, if exiftool is converting the output for the following command to local time, then it should still show that same original timestamp + timezone.  It shouldn't show this strange combination of the corrected time but also the local/original timezone:

Code Select Expand

% exiftool -dateFormat "%Y:%m:%d %H:%M:%S%z" -DateTimeOriginal /path/to/some.CR3
Date/Time Original              : 2025:08:04 07:29:55-0700
# it's showing the time forward 3 hours, but now with a timezone that doesn't make sense
I'm just trying to make sense of what exiftool is doing in this command that simply prints the DateTimeOriginal tag.

--

Here is the output of the -time:all command:

Code Select Expand

exiftool -time:all -G1 -a -s  /Volumes/SamsungEvo4TB/import-2025-08-05-keepers/hotel4th/R5PT4109.CR3
[System]        FileModifyDate                  : 2025:08:09 12:12:57-07:00
[System]        FileAccessDate                  : 2025:08:09 12:12:58-07:00
[System]        FileInodeChangeDate             : 2025:08:09 12:12:57-07:00
[IFD0]          ModifyDate                      : 2025:08:04 07:29:55
[ExifIFD]       DateTimeOriginal                : 2025:08:04 07:29:55
[ExifIFD]       CreateDate                      : 2025:08:04 07:29:55
[ExifIFD]       OffsetTime                      : -04:00
[ExifIFD]       OffsetTimeOriginal              : -04:00
[ExifIFD]       OffsetTimeDigitized             : -04:00
[ExifIFD]       SubSecTime                      : 59
[ExifIFD]       SubSecTimeOriginal              : 59
[ExifIFD]       SubSecTimeDigitized             : 59
[Canon]         TimeZone                        : -04:00
[Canon]         TimeZoneCity                    : New York
[Canon]         DaylightSavings                 : On
[QuickTime]     CreateDate                      : 2025:08:04 07:29:55-07:00
[QuickTime]     ModifyDate                      : 2025:08:04 07:29:55-07:00
[Track1]        TrackCreateDate                 : 2025:08:04 04:29:55-07:00
[Track1]        TrackModifyDate                 : 2025:08:04 04:29:55-07:00
[Track1]        MediaCreateDate                 : 2025:08:04 04:29:55-07:00
[Track1]        MediaModifyDate                 : 2025:08:04 04:29:55-07:00
[Track2]        TrackCreateDate                 : 2025:08:04 04:29:55-07:00
[Track2]        TrackModifyDate                 : 2025:08:04 04:29:55-07:00
[Track2]        MediaCreateDate                 : 2025:08:04 04:29:55-07:00
[Track2]        MediaModifyDate                 : 2025:08:04 04:29:55-07:00
[Track3]        TrackCreateDate                 : 2025:08:04 04:29:55-07:00
[Track3]        TrackModifyDate                 : 2025:08:04 04:29:55-07:00
[Track3]        MediaCreateDate                 : 2025:08:04 04:29:55-07:00
[Track3]        MediaModifyDate                 : 2025:08:04 04:29:55-07:00
[Track4]        TrackCreateDate                 : 2025:08:04 04:29:55-07:00
[Track4]        TrackModifyDate                 : 2025:08:04 04:29:55-07:00
[Track4]        MediaCreateDate                 : 2025:08:04 04:29:55-07:00
[Track4]        MediaModifyDate                 : 2025:08:04 04:29:55-07:00
[Track4]        TimeStamp                       : 2025:08:04 04:29:55.59
[Composite]     SubSecCreateDate                : 2025:08:04 07:29:55.59-04:00
[Composite]     SubSecDateTimeOriginal          : 2025:08:04 07:29:55.59-04:00
[Composite]     SubSecModifyDate                : 2025:08:04 07:29:55.59-04:00

[Phil Harvey]

DateTimeOriginal doesn't contain a time zone, so when you add a %z formatting code the system time zone is used.  Use the Composite SubSecDateTimeOriginal tag instead, then you should get the time zone you expect.

From the Notes for the -d option:

        1) %z represents the time zone in "+/-HHMM" format. Adding a colon
         (ie. %:z) adds a colon separator (eg. "-05:00"). If the date/time
         value doesn't contain a time zone then %z gives the system time
         zone for the specified date/time value.

- Phil

[ptdotme]

Ok thanks.  Is there a historical reason why the -d option behaves this way?  The "Composite" value for DateTimeOriginal works as expected.  If a timezone is requested, why wouldn't the one present in other tags suffice?

Thanks again!

[Phil Harvey]

It is the job of the Composite tags to combine values from other tags.  Other (non-Composite) tags are independent entities, and it would be confusing/complicated otherwise.

- Phil

[ptdotme]

I see where you're coming from, but by appending the local system timezone exiftool is already no longer showing the DateTimeOriginal as an independent value.  It seems to me like it would be less confusing if it appended the timezone value the user would expect.  I might prefer an error to be output ("timezone cannot be output because DateTimeOriginal doesn't contain that information") but I can see why it's better to pick a sensible fallback value.  Thanks again for the quick response.

[Phil Harvey]

by appending the local system timezone exiftool is already no longer showing the DateTimeOriginal as an independent value

I respectfully disagree.  Date/time values are always relative to some time zone, and it is often convenient to show them relative to the current system time zone, but this is configurable via the API TimeZone option.  It is a special case that this specific tag has a related tag which may provide the actual time zone.  If the EXIF creators had a brain to share amongst them then the time zone would have been included in the original tag in the first place instead of being added as an afterthought in a separate tag.  So I blame them for your issue.

- Phil

[ptdotme]

Thanks for the clarification.  I understand you've thought about this for far longer than I have, but hopefully my outsider viewpoint is useful in some way.

it is often convenient to show them relative to the current system time zone

I agree with this, but exiftool is not showing the DateTimeOriginal time "relative" to the local timezone.  It's just appending it.  For that reason a warning message ("Using the default local timezone with DateTimeOriginal may result in incorrect timestamps.  Use SubSecDateTimeOriginal or the -api TimeZone option instead.") would have really helped me.  The warning message could be displayed only if the OffsetTime tags don't match the local machine timezone.

In case someone comes along looking at this thread later, I'd like to show the -api TimeZone workaround for my issue:

Code Select Expand

# correct output with SubSecDateTimeOriginal
% exiftool -dateFormat "%Y %Y:%m:%d %H:%M:%S%z" -SubSecDateTimeOriginal /path/to/R5PT4109.CR3
Date/Time Original              : 2025 2025:08:04 07:29:55-0400

# incorrect timezone assumed by default for DateTimeOriginal
% exiftool -dateFormat "%Y %Y:%m:%d %H:%M:%S%z" -DateTimeOriginal /path/to/R5PT4109.CR3
Date/Time Original              : 2025 2025:08:04 07:29:55-0700

# override assumed local timezone with -api option (note positive timezone offset given)
% exiftool -api TimeZone=+04:00 -dateFormat "%Y %Y:%m:%d %H:%M:%S%z" -DateTimeOriginal /path/to/R5PT4109.CR3
Date/Time Original              : 2025 2025:08:04 07:29:55-0400

[Phil Harvey]

I hear what you are saying, and I'm sorry that you wasted some time being confused about ExifTool's behaviour in this case, but implementing your suggestions would be just the tip of a very deep and very painful iceberg.

Given that I can't recall anyone else having this issue, I'm hoping it won't impace too many other users.

- Phil