Wrong file time set for *.mov

[HansS713]

I have e.g a MOV file, taken 2011-07-08 23:08:03 with Canon IXUS 990 IS, but ExifTool shows 2011-07-08 21:08:03 (note the 21 instead of 23), and so the command

exiftool "-FileModifyDate<CreateDate" *.M*

sets wrong date. Maybe the camera or ExifTool handles time zones wrong - but camera has no information about time zone (only a DST setting to change the time easy by 1h).

Time of *.JPG from same camera is OK.

Even if the error is caused by the camera (e.g. wrong or missing time zone information), then ExifTool should have an option to work around this problem. I haven't tested if I could simply add 2h (could I do this for file time only without changing the value in the file - *.MOV are supported for read only), but this would not be a real solution anyway, because I don't know in a script if the time is in summer (DST active, 2h difference) or in winter (DST not active, 1h difference).


PS.: According to ISO standard date should be written as YYYY-MM-DD (not with ":").

Here the complete meat information of one of the files (after ExifTool has already set the wrong file time):

Code Select Expand


ExifTool Version Number         : 8.60
File Name                       : MVI_2093.MOV
Directory                       : .
File Size                       : 3701 MB
File Modification Date/Time     : 2011:07:08 21:08:03+02:00
File Permissions                : rw-rw-rw-
File Type                       : MOV
MIME Type                       : video/quicktime
Major Brand                     : Apple QuickTime (.MOV/QT)
Minor Version                   : 2007.9.0
Compatible Brands               : qt  , CAEP
Movie Data Size                 : 3880143308
Movie Header Version            : 0
Create Date                     : 2011:07:08 21:08:03
Modify Date                     : 2011:07:08 21:08:03
Time Scale                      : 3000
Duration                        : 0:21:36
Preferred Rate                  : 1
Preferred Volume                : 100.00%
Preview Time                    : 0 s
Preview Duration                : 0 s
Poster Time                     : 0 s
Selection Time                  : 0 s
Selection Duration              : 0 s
Current Time                    : 0 s
Next Track ID                   : 3
Track Header Version            : 0
Track Create Date               : 2011:07:08 21:08:03
Track Modify Date               : 2011:07:08 21:08:03
Track ID                        : 1
Track Duration                  : 0:21:36
Track Layer                     : 0
Track Volume                    : 0.00%
Image Width                     : 1280
Image Height                    : 720
Graphics Mode                   : srcCopy
Op Color                        : 0 0 0
Compressor ID                   : avc1
Source Image Width              : 1280
Source Image Height             : 720
X Resolution                    : 72
Y Resolution                    : 72
Bit Depth                       : 24
Video Frame Rate                : 30
Matrix Structure                : 1 0 0 0 1 0 0 0 1
Media Header Version            : 0
Media Create Date               : 2011:07:08 21:08:03
Media Modify Date               : 2011:07:08 21:08:03
Media Time Scale                : 44100
Media Duration                  : 0:21:36
Balance                         : 0
Handler Class                   : Data Handler
Handler Type                    : Alias Data
Audio Channels                  : 1
Audio Bits Per Sample           : 16
Audio Sample Rate               : 44100
Audio Format                    : chan
Compressor Version              : CanonAVC0001
Avg Bitrate                     : 23.9 Mbps
Image Size                      : 1280x720
Rotation                        : 0


[Phil Harvey]

Hi Hans,

Thanks for the report.  I have some questions/comments:

I have e.g a MOV file, taken 2011-07-08 23:08:03 with Canon IXUS 990 IS, but ExifTool shows 2011-07-08 21:08:03 (note the 21 instead of 23)

The QuickTime specificate states that the stored time should be in UTC.  What is your system timezone?  It seems like the problem may be that ExifTool is adjusting to local time when it shouldn't be.

PS.: According to ISO standard date should be written as YYYY-MM-DD (not with ":").

Yes, but ExifTool uses EXIF date/time formatting.  However, you can use whatever format you like with the -d option.

- Phil

[HansS713]

Hi Phil.

If it should be UTC then the displayed values are correct - as you see from file time I'm at +2 (European DTS), so local time 23:08:03 is 21:08:03Z. But I wonder how the camera could enter correct UTC, because I found no time zone setting in the camera!? So it may be very well not correct filled data by the camera (but even in this case ExifTool may offer some workaround).

Anyway, if ExifTool displays 21:08:03 for "Create Date", and if this is really meant as UTC, then local file time should be set correct to 23:08:03, but this is not the case. Does ExifTool show the "raw" value, or do you do some conversion? Btw., I think it would make things more clear if you would mark UTC times as UTC, e.g. with "Z" or "+0".

If it would help I can create a short MOV and send it to you, so you can check what's really in the file. Let me know if I can help in any way to solve this problem.

Thanks for this great tool,
Hans

[Phil Harvey]

Hi Hans,

I took a look at my code, and ExifTool does not convert QuickTime date/time values to the local time zone.  There is a note in the code that the these values are only inconsistently stored as UTC, and for that reason the time isn't converted to local.

Does ExifTool show the "raw" value, or do you do some conversion?

In QuickTime movies, the raw date/time values are a 32-bit integer, something like "3206613834".  So ExifTool must convert this to a readable format.

Btw., I think it would make things more clear if you would mark UTC times as UTC, e.g. with "Z" or "+0".

I do show time zone information if it is known (ie. FileModificationDate, which is stored as UTC and converted to local time by ExifTool).  Unfortunately it seems that we don't have reliable time zone information for the QuickTime tags.

If it would help I can create a short MOV and send it to you, so you can check what's really in the file.

Sure.  Send me a small file and tell me what the camera time was set to, and what your corresponding local time was. (philharvey66 at gmail.com)

- Phil

[HansS713]

Hi Phil.

An example as requested is just sent by mail.

1. Taken 13:07 local European DST (+2 = 11:07Z)

2. File time of this example is lost by (stupid) Win7 function to copy files from camera (unfortunately the Canon IXUS 990 IS does not show its data as mass storage device, and on this computer I have no chip drive, and I prefer to simply connect camera via USB instead of moving SD cards around anyway).

3. After "exiftool "-FileModifyDate<CreateDate" *.M* file time is set to 11:07:23 (instead of 13:07:23).

4. I finally fond the time zone setting in the camera . So it's obvious that the camera really stores the time in correct UTC (if the camera settings are correct). I tried to change the time zone to +3 (Kairo), made a test MOV at 14:24 (faked +3), see 11:24:42Z in the QuickTime header, and get file time 11:24:42 (instead of 14:24:42) from ExifTool.

5. You wrote: "There is a note in the code that these values are only inconsistently stored as UTC, and for that reason the time isn't converted to local.". I agree, I can imagine that simple cameras don't have time zone information (or that it's not set correctly), and I think the only solution is to add new command line option(s) to turn "UTC to Local" - conversion on or off. If you already handle it differently for different file types, then different options for the different file types may be sufficient.

Kind regards
Hans

[Phil Harvey]

This all makes sense now.  The inconsistency in the MOV time zone would require a special option just for this, but I don't like to introduce new command-line options for things like this (there are too many command-line options already).  Perhaps a new configuration option though.  I will have to think about this.

For now, you can execute 2 commands to do what you want:

exiftool "-FileModifyDate<CreateDate" -ext mov DIR

exiftool -FileModifyDate+=2 -ext mov DIR

Unfortunately this must be done as 2 separate commands, but at least it will allow you to set the proper file modification date/time.  However, the 2 commands can be combined into a single command line if you want:

exiftool "-FileModifyDate<CreateDate" -execute -FileModifyDate+=2 -common_args -ext mov DIR

- Phil

[HansS713]

Hi Phil.

Thanks for your tip. But this is only a temporary solution: I use a script to rename and set time of all pictures and movies from my camera. To correct the wrong time stamp I would need to know if the CreateDate is in summer or winter to know if I need 1h or 2h correction.

Is there an chance for a fix in ExifTool until DST ends – in this case I would save the effort writing an own program or script to change file time from UTC to local.

Kind regards
Hans

[Phil Harvey]

There is a chance I can come up with a solution.  It is on my list to consider this for the next release.

- Phil

[Phil Harvey]

Sorry that this missed the 8.62 release, but in version 8.63 I plan to add a QuickTimeUTC option to the API to give you control over this behaviour.  If this option is set, then the QuickTime date/time values are assumed to be in UTC and are then converted to local time.

To enable this option by default, the following config file may be used:

Code Select Expand

%Image::ExifTool::UserDefined::Options = (
    QuickTimeUTC => 1,      # assume Quicktime date/time tags are stored as UTC
);
1;  #end

- Phil

[HansS713]

Hi Phil.

We are at v8.68 meanwhile - but I don't see the QuickTimeUTC option ? Did I miss something?

Hans

[Phil Harvey]

Hi Hans,

It isn't a command-line option.  It is an API option that you may define through the config file as I mentioned in my last post.  See the bottom of the sample config file for an example of how to use these options, and the Options function documentation for a complete list of options.

- Phil

[wildcowboy]

exiftool "-FileModifyDate<CreateDate" -execute -FileModifyDate+=2 -common_args -ext mov DIR

Hello Phil,
If I want to add -overwrite_original where should I put it in this command line? before -execute or after -common_args

[Phil Harvey]

The -overwrite_original would have no effect anyway -- you are only setting "pseudo" System tags so the file is not actually written.

- Phil

[StarGeek]

What Phil said, but if you were doing some other command where the file would be written to

• exiftool SomeCommand -overwrite_original -execute AnotherCommand -common_args  DIR
  SomeCommand would not have a backup original file written.  AnotherCommand would get a backup file.
• exiftool SomeCommand -execute -overwrite_original AnotherCommand -common_args  DIR
  The opposite, backup file for SomeCommand, none for AnotherCommand
  
• exiftool SomeCommand -execute -overwrite_original AnotherCommand -common_args -overwrite_original DIR
  No backup file would be written, as -overwrite_original would be common to both commands.