Author Topic: QuickTime:DateTimeOriginal written automatically, without timezone conversion  (Read 998 times)

Phil Harvey

  • ExifTool Author
  • Administrator
  • ExifTool Freak
  • *****
  • Posts: 16885
    • ExifTool Home Page
BTW, there was a report here that using QuickTime:DateTimeOriginal may confuse Apple Photos, although I couldn't reproduce this myself.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

torarnv

  • Jr. Member
  • **
  • Posts: 15
The only reason I knew that it existed is because some program I've used recently set that tag.  I still can't figure out which one, though, and it's bugging the heck out of me.

That could have been exiftool itself? That's what happened to me at least, as I was setting AllDates which will write both XMP:DateTimeOriginal and QuickTime:DateTimeOriginal.

torarnv

  • Jr. Member
  • **
  • Posts: 15
Quote
Does the same apply when doing -QuickTime:DateTimeOriginal<SomeDateTagThatDoesntEncodeUTCOffsetOrIsExplcitlyInUTC?

At this level, the value of the source tag is a string.  It doesn't matter where it comes from.

Ah, I see. Does it go via the -d format in that case? So with the default format that doesn't include a time zone offset it would lose the (possible) UTC offset in the original tag?

Quote
Quote
Perhaps it would be useful with an option to always write string dates with an UTC offset?
This is a good idea.

Hurray :)

Another thing that crossed my mind was that the geolocation info could potentially be used to decide which timezone input dates without timezone should be interpreted as, instead of always assuming the local timezone (as I understand it does now?).

Cheers,
Tor Arne

Phil Harvey

  • ExifTool Author
  • Administrator
  • ExifTool Freak
  • *****
  • Posts: 16885
    • ExifTool Home Page
Hi Tor,

Ah, I see. Does it go via the -d format in that case?

Yes.

Quote
So with the default format that doesn't include a time zone offset it would lose the (possible) UTC offset in the original tag?

Again, I think you are confused.  If the date/time tag has a time zone then the "default format" will include that time zone.

Quote
Quote
Quote
Perhaps it would be useful with an option to always write string dates with an UTC offset?
This is a good idea.

Hurray :)

I think we miscommunicated again here.  I meant that it is a good idea to always write the time zone.  But ExifTool is not going to do that for you.  That's something you need to do yourself.

Quote
Another thing that crossed my mind was that the geolocation info could potentially be used to decide which timezone input dates without timezone should be interpreted as, instead of always assuming the local timezone (as I understand it does now?).

There is a config file include in the full distribution that attempts to determine the time zone of an image like this.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

StarGeek

  • Global Moderator
  • ExifTool Freak
  • *****
  • Posts: 3964
That could have been exiftool itself? That's what happened to me at least, as I was setting AllDates which will write both XMP:DateTimeOriginal and QuickTime:DateTimeOriginal.

No, I don't use AllDates with video files.  I rarely use it at all, since I have my own shortcuts which are more targeted and explicit as to which tags they set.

It was a program more video specific.  I thought it might have been Youtube-DL, but that sets ContentCreateDate, which shows just the date without formatting, like 20190516.  Unfortunately, it doesn't appear to set any other time stamps while using the --add-metadata switch.

Troubleshooting hints:
* When posting, include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).
* Double all percent signs (%) in a Windows batch file.
* If your GPS coords are negative, make sure and set the GpsLatitudeRef and GpsLongitudeRef tags correctly.