Author Topic: Difference of 1 hour between EXIF DateTimeOriginal and {File.DateTime}  (Read 356 times)

achim1208

  • New Members
  • *
  • Posts: 2
Up to now the value of the variable {File.DateTime} always was the same as the EXIF timestamp Exif::Main\36867\DateTimeOriginal for all Nikon D90 images in my IMatch database.
In the case of newly imported images, the time in the variable {File.DateTime} now differs by +1 hour from the time in Exif::Main\36867\DateTimeOriginal.
Even if I import a picture imported some months before again now, 1 hour is added to the EXIF DateTimeOriginal.

Is this a new behavior when importing images and what can I do that the times in Exif::Main\36867\DateTimeOriginal and {File.DateTime} match again?

I have added the Reports of the Metadata Analyst for 2 images.
Metadata Analyst Results - DateTimeOriginal+0h.txt --> no difference between Exif::Main\36867\DateTimeOriginal and {File.DateTime}
Metadata Analyst Results - DateTimeOriginal+1h.txt --> the same image with 1 h difference between Exif::Main\36867\DateTimeOriginal and {File.DateTime}

Achim

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 28570
Keep in mind that IMatch displays time in local time, and we recently switched to DST.
Maybe check Edit menu > Preferences > Metadata 2: Apply Time zone...

EXIF does not have a time zone (sans the occasional attempts by some camera vendors).
If you're dealing with time-zone related issues, it's best to pin the proper time in the IMatch Metadata Panel by adding the time-zone the images were taking in. Or using the TimeWiz app to shift/set the time-zone as needed.

akirot

  • Full Member
  • **
  • Posts: 191
Quote
EXIF does not have a time zone (sans the occasional attempts by some camera vendors).

This is wrong, see e.g. Wikipedia (search for "Exif") as a secondary source:

Quote
However, time-zone information has been introduced recently by Exif version 2.31 (July 2016). Related tags are: "OffsetTime", "OffsetTimeOriginal" and "OffsetTimeDigitized".

The OffsetTimes also take daylight savings into account.

Quote
If you're dealing with time-zone related issues, it's best to pin the proper time in the IMatch Metadata Panel by adding the time-zone the images were taking in. Or using the TimeWiz app to shift/set the time-zone as needed.

Yes, in fact adding/correcting time-zones is the only way to overcome this dilemma.

BTW after a forced rescan of some files (with all timezones) after the recent daylight savings switch they were shifted by one hour. I don't have time to scrutinize that further - just to inform you, Mario, be alerted.

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 28570
Which EXIF timestamps does ExifTool show for your files? Usually IMatch considers TZO when found in the image metadata.
Do your files already contain XMP? Do your files contain legacy IPTC?
What is your local time zone and is DST active in your time zone? At which time did you ingest the files, before or after DST was effective?
Did you set your camera to your local time-zone and also changed to DST (if the camera does not do it automatically)?
Feel free to send a sample image which exhibits this behavor to support email address, with a link back to this thread.

achim1208

  • New Members
  • *
  • Posts: 2
Quote
What is your local time zone and is DST active in your time zone?
My local time zone is CET and DST is active at the moment (UTC+2h).

Quote
At which time did you ingest the files, before or after DST was effective?
It doesn't seem to matter when the photos were taken, rather with which camera and with which EXIF data.
I have investigated 4 cases.

Apple iPhone Xs, CEST: {File.DateTime} has the correct value
Code: [Select]
{File.DateTime}                                 : 28.09.2020 07:23:45
[File:System]   FileModifyDate                  : 2020:09:28 07:23:45+02:00
[File:System]   FileAccessDate                  : 2021:04:02 12:20:59+02:00
[File:System]   FileCreateDate                  : 2021:04:02 12:19:58+02:00
[EXIF:IFD0]     ModifyDate                      : 2020:09:28 07:23:45
[EXIF:ExifIFD]  DateTimeOriginal                : 2020:09:28 07:23:45
[EXIF:ExifIFD]  CreateDate                      : 2020:09:28 07:23:45
[EXIF:ExifIFD]  OffsetTime                      : +02:00
[EXIF:ExifIFD]  OffsetTimeOriginal              : +02:00
[EXIF:ExifIFD]  OffsetTimeDigitized             : +02:00
[EXIF:ExifIFD]  SubSecTimeOriginal              : 708
[EXIF:ExifIFD]  SubSecTimeDigitized             : 708
[EXIF:GPS]      GPSDateStamp                    : 2020:09:28
[ICC_Profile:ICC-header] ProfileDateTime        : 2017:07:07 13:22:32
[Composite]     SubSecCreateDate                : 2020:09:28 07:23:45.708+02:00
[Composite]     SubSecDateTimeOriginal          : 2020:09:28 07:23:45.708+02:00
[Composite]     SubSecModifyDate                : 2020:09:28 07:23:45+02:00

Nikon D90, CEST: {File.DateTime} does not have the correct value
Code: [Select]
{File.DateTime}                                 : 28.09.2020 10:41:29
[File:System]   FileModifyDate                  : 2020:09:28 09:41:30+02:00
[File:System]   FileAccessDate                  : 2021:04:02 12:18:59+02:00
[File:System]   FileCreateDate                  : 2021:04:02 12:10:40+02:00
[EXIF:IFD0]     ModifyDate                      : 2020:09:28 09:41:29
[EXIF:ExifIFD]  DateTimeOriginal                : 2020:09:28 09:41:29
[EXIF:ExifIFD]  CreateDate                      : 2020:09:28 09:41:29
[MakerNotes:Nikon] TimeZone                     : +01:00
[MakerNotes:Nikon] DaylightSavings              : Yes
[MakerNotes:Nikon] DateDisplayFormat            : D/M/Y
[MakerNotes:Nikon] PowerUpTime                  : 2020:09:28 09:41:17
[EXIF:ExifIFD]  SubSecTime                      : 00
[EXIF:ExifIFD]  SubSecTimeOriginal              : 00
[EXIF:ExifIFD]  SubSecTimeDigitized             : 00
[Composite]     SubSecCreateDate                : 2020:09:28 09:41:29.00
[Composite]     SubSecDateTimeOriginal          : 2020:09:28 09:41:29.00
[Composite]     SubSecModifyDate                : 2020:09:28 09:41:29.00

Apple iPhone Xs, CET: {File.DateTime} does not have the correct value
Code: [Select]
{File.DateTime}                                 : 06.03.2021 12:41:36
[File:System]   FileModifyDate                  : 2021:03:06 11:41:36+01:00
[File:System]   FileAccessDate                  : 2021:04:02 12:20:59+02:00
[File:System]   FileCreateDate                  : 2021:04:02 12:20:50+02:00
[EXIF:IFD0]     ModifyDate                      : 2021:03:06 11:41:36
[EXIF:ExifIFD]  DateTimeOriginal                : 2021:03:06 11:41:36
[EXIF:ExifIFD]  CreateDate                      : 2021:03:06 11:41:36
[EXIF:ExifIFD]  OffsetTime                      : +01:00
[EXIF:ExifIFD]  OffsetTimeOriginal              : +01:00
[EXIF:ExifIFD]  OffsetTimeDigitized             : +01:00
[EXIF:ExifIFD]  SubSecTimeOriginal              : 684
[EXIF:ExifIFD]  SubSecTimeDigitized             : 684
[ICC_Profile:ICC-header] ProfileDateTime        : 2017:07:07 13:22:32
[Composite]     SubSecCreateDate                : 2021:03:06 11:41:36.684+01:00
[Composite]     SubSecDateTimeOriginal          : 2021:03:06 11:41:36.684+01:00
[Composite]     SubSecModifyDate                : 2021:03:06 11:41:36+01:00

Nikon D90, CET: {File.DateTime} does not have the correct value
Code: [Select]
{File.DateTime}                                 : 06.03.2021 12:41:54
[File:System]   FileModifyDate                  : 2021:03:06 11:41:54+01:00
[File:System]   FileAccessDate                  : 2021:04:02 12:18:59+02:00
[File:System]   FileCreateDate                  : 2021:04:02 12:10:13+02:00
[EXIF:IFD0]     ModifyDate                      : 2021:03:06 11:41:54
[EXIF:ExifIFD]  DateTimeOriginal                : 2021:03:06 11:41:54
[EXIF:ExifIFD]  CreateDate                      : 2021:03:06 11:41:54
[MakerNotes:Nikon] TimeZone                     : +01:00
[MakerNotes:Nikon] DaylightSavings              : No
[MakerNotes:Nikon] DateDisplayFormat            : D/M/Y
[MakerNotes:Nikon] PowerUpTime                  : 2021:03:06 11:41:47
[EXIF:ExifIFD]  SubSecTime                      : 00
[EXIF:ExifIFD]  SubSecTimeOriginal              : 00
[EXIF:ExifIFD]  SubSecTimeDigitized             : 00
[Composite]     SubSecCreateDate                : 2021:03:06 11:41:54.00
[Composite]     SubSecDateTimeOriginal          : 2021:03:06 11:41:54.00
[Composite]     SubSecModifyDate                : 2021:03:06 11:41:54.00

As you can see, only the photo taken with the iphone during DST will be imported with the correct time.

I found out that all 4 photos are imported with the correct time if I set the option "Apply time-zone" under Edit/Preferences/Metadata 2 to "no".
Until now, this option was always set to "yes".
I have imported about 51k objects (images and movies) to my IMatch database until now.
I checked all objects with an export of the metadata.
There is no difference in the database between {File.DateTime} and EXIF timestamp Exif :: Main \ 36867 \ DateTimeOriginal for any object that has EXIF data.

My question is, has the procedure for determining the value of the variable {File.DateTime} been changed in the meantime?
Is it necessary now to set the option "Apply time-zone" to "no"?

Achim

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 28570
Did you send me these files per email? This would help with testing a lot.
When "Apply time zone is on", IMatch applies the time-zone found in the base tag used when determining the File.DateTime (depends on the file format and metadata available and what ExifTool delivers, see How IMatch uses Date and Time Information). Else not.

Looking at an XMP date 2020:06:21 11:09:11.541-06:00 IMatch can use either 2020:06:21 11:09:11.541 or 21.06.2020 19:09:11 for the DateTime variable, depending on which setting you use for this option. DateTime carries no time-zone information.
« Last Edit: April 04, 2021, 01:28:32 PM by Mario »

akirot

  • Full Member
  • **
  • Posts: 191
I invested some time on it and think I could encircle the bug.
At least I can reproduce the behaviour with CR2 and CR3 Raws.

The problem occurs when "Apply time zone" is set to "Yes" and the timezones of the image and the PC IMatch runs on differ when ingesting or rescanning the image.

To reproduce:

The very same image taken at German winter time (i.e. Timezone = +1)

a) ingested at German winter time delivers the correct File.DateTime.

b) ingested/rescanned now at German summer time (i.e. Timezone = +2) shifts File.DateTime by 1 hour as per attached screen shot of the MetaData analyst.
Neither is File.DateTime UTC nor is it local time - it is wrong.

Changing "Apply time zone" to "No" delivers correct File.DateTime (after having rescanned the image).

My images contain all three times (taken, created, modified) including the respective offset times - so, no reason for any Timezone guessing.

If I may speculate:
I don't know how IMatch identifies whether an image contains timezones or not.
To me the three offset times look like a good criteria.
(Some years ago there has been a "TimeZoneOffset" tag [see the difference to the "offset..." tags] around. Geosetter e.g. made use of it. Today it is not used widely and it should not be used alone to determine whether an image contains timezone information or not.)

For IMatch 2021 I recommend changing File.DateTime (which is more or less IMatch internal) to UTC. This would simplify all timesorting - even across timezones.
It's user responsibilty to attach the correct timezones to the images - which is an easy task with the already available IMatch features.

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 28570
Keep in mind that variables and DateTime display local time.
IMatch uses the timezone offsets reported by ExifTool  for the EXIF offsets. See my example above.
Send me a sample file. I could not reproduce your problem with the files I've used and I've always got the correct result as explained above in my reply.
If your time-zone is +01:00, check what datetime variables return first (always in your local time).

Quote
For IMatch 2021 I recommend changing File.DateTime (which is more or less IMatch internal) to UTC.

This timestamp is used since IMatch 3. Changing it could break a lot of things out there.
IMatch internally uses UTC for other things, but for a user-facing timestamp a timestamp in local time is much preferred.

akirot

  • Full Member
  • **
  • Posts: 191
Quote
Keep in mind that variables and DateTime display local time.
That's my expectation - but they don't as my screen shot above shows. DateTime is one hour ahead.
Looking at your example:
Quote
Looking at an XMP date 2020:06:21 11:09:11.541-06:00 IMatch can use either 2020:06:21 11:09:11.541 or 21.06.2020 19:09:11 for the DateTime variable, depending on which setting you use for this option. DateTime carries no time-zone information.
I'm confused: yes, 11:09:11 is the correct local time but how do you derive 19:09:11 as a possible local time for DateTime? (Or is this just a typo?)
I'm not sure we are on the same side: Standard always has been the local time of (the location of) shooting (or modification as far as modification time is concerned). Eventually some years ago offsettimes were added to the standard for clarification.
Have you taken into account the offsettime of the PC IMatch runs on changing halfyearly forth and back because of daylight savings - whilst of course the offsettimes of the images taken don't change?
DateTime currently gets different values depending on the time (and offsettime) when IMatch ingests or rescans images.
In my case I had a sequence of shots taken and ingested during wintertime, nicely displayed and sorted by capture time. I rescanned one(!) of these images in summertime(!) which directly became out of sequence because datetime moved one hour ahead. This cannot be the wanted behaviour. By no means did the rescanned image (including times and offsettimes) change.

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 28570
No typo I guess. The offset to UTC of the file + the local time zone offset at the time of ingest.
Please send me the file you have used for testing. All else is just guesswork.
« Last Edit: April 10, 2021, 08:21:06 PM by Mario »