"AllDates" represent not the main times in any way

Started by Jens0079, December 31, 2013, 08:31:37 AM

Previous topic - Next topic

Phil Harvey

ExifTool displays numerical times in the local system timezone if the absolute time is known and the value doesn't specify a time zone.  A good example of this are the System times.

If the absolute time is not known, then no time zone is displayed.  This is the default for numerical QuickTime date/time tags.

Date/time values stored as strings are not changed, other than some string reformatting to use a consistent date/time format.

I can't see any other reasonable way that ExifTool could handle the date/time tags, so I am confused about why you seem to have problems understanding this, unless it is just a communication problem.

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

Jens0079

Hi Phil,

QuoteIf the absolute time is not known, then no time zone is displayed.  This is the default for numerical QuickTime date/time tags.
That's the lack of understanding from me.

I thought it is displayed in the timezone +00:00. I thought you doesn't write it because it is zero. (Like 123,000000 = 123)
I tried a Mac time converter from the internet. (http://fmdiff.com/fm/timestamp.html)
3471508735 => 12:58:55 (This is my correct local time for this file). You displays 11:58:55 in exiftool output so I thought you took my system timezone (+01:00) and convert the 3471508735 which represent 12:58:55 back to +00:00 because of the difference of one hour between the time converter and your exiftool output.



-Jens
macOS Sierra

Phil Harvey

For example, this is what I get in my timezone for a sample iPhone 4 video that I have here:

> exiftool ../pics/Apple_iPhone4.mov -createdate -H -a
0x0001 Create Date                     : 2010:06:25 21:50:16
     - Create Date                     : 2010:06:25 17:50:16-04:00

> exiftool ../pics/Apple_iPhone4.mov -createdate -H -a -api QuickTimeUTC
0x0001 Create Date                     : 2010:06:25 17:50:16-04:00
     - Create Date                     : 2010:06:25 17:50:16-04:00

> exiftool ../pics/Apple_iPhone4.mov -v | grep -w CreateDate
  | | CreateDate = 3360347416
  | | CreateDate = ...2010-06-25T17:50:16-0400


So for this video the numerical date/time values are based on UTC time zero, and ExifTool converts the times properly with the QuickTimeUTC option.

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

Jens0079

Hi Phil!

Thanks, now I know "my" mistake.
My posted timeconverter link displays your seconds (3360347416) at "Friday, 2010-06-25 23:50:16 (UTC)" That's wrong. This are these seconds in MY timezone. Not at UTC zero like it is displayed in the brackets.
I found another converter which makes it right. http://www.epochconverter.com/epoch/mac-timestamp.php

With that I have the output of 3360347416 seconds

  • GMT: Fri, 25 Jun 2010 21:50:16 GMT
  • Your time zone (my time zone ;)): 25.06.2010 23:50:16
That's right!

So because of the wrong output from the first converter I thought the time is saved at "local time" and you convert it back to UTC zero.

Now I understand your output of the times. And for my cameras (iPhone, Fuji) it make sense to enable -api QuickTimeUTC=1 because both store the time relative to UTC zero.

-Jens
macOS Sierra

Phil Harvey

Hi Jens,

Ah.  Glad you figured this out.  I wasn't thinking about a problem in your time converter.  That certainly would cause this confusion.

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