-fileModifyDate<dateTimeOriginal - timezones in MTS & M2TS (H264) files

[justin.nm]

Hi,

I've had some success changing the File System Date Modified to reflect the H264 dateTimeOriginal field in m2ts files and mts using the following in Windows 7 x64:

Code Select Expand

exiftool "-fileModifyDate<dateTimeOriginal" -ext mts -ext m2ts -ext mp4 -ext mov -ext mod %*


However there is a problem when the files are not taken in the same timezone, due to the fact that timezone is included in the dateTimeOriginal field for H264.


Example: An MTS video file was taken in Perth (+8:00), but I am located in Melbourne (+10:00) Australia.

The MTS file has a Date/Time Original of:

Code Select Expand

2011:08:18 10:53:56+08:00

After running exiftool with my original command, the File Modification Date/Time is now:

Code Select Expand

2011:08:18 12:53:56+10:00

it has shifted to account for the timezone, difference, but I do not want it to. I want the File Modification Date/Time to be the exactly the same as the Date/Time Original. This is so when one opens the properties of the the file in Windows Explorer, they can see the original date and time the video was taken at by looking at the Date Modified field.

I thought I had a workaround:

Code Select Expand

exiftool "-fileModifyDate<dateTimeOriginal+10:00" -ext mts -ext m2ts -ext mp4 -ext mov -ext mod %*

but that does not solve the problem entirely as then you'd need a unique command if you're in a different timezone.


Is there a way for exiftool to "ignore" the timezone in the dateTimeOriginal field for MTS and M2ts (H264) files?


Thanks in advance for any help or tips,

Justin.

[Phil Harvey]

Hi Justin,

I think this may do what you want:

exiftool "-fileModifyDate<${dateTimeOriginal;s/[-+].*//}" -ext mts -ext m2ts -ext mp4 -ext mov -ext mod %*

This removes the time zone from the DateTimeOriginal before using it to set FileModifyDate.

- Phil

Edit:  Thinking about this, you may still have a one-hour difference if there is a daylight savings time change on your system between when the video was taken and the current system time.  The only way I can think of getting around this is to add the current timezone back again as you mentioned, but this isn't very appealing.

I should note that what you are doing will actually set the wrong time for the video in an absolute sense, and will also give an incorrect local time if the system timezone subsequently changes (so in fact there is no way around the daylight savings time problem).

[justin.nm]

Hi Phil,

Thanks for taking the time to look at my thread.

The File System FileModifyDate works in strange ways, at least in Windows 7. As soon as one changes the timezone in Windows, it changes all the File System dates (modified and accessed) on all files to adjust accordingly. I can see how this relative time is useful for some, but rather annoying for my use.

Your command is about as close and I'll get. There doesn't seem to be a way around it otherwise. When DST rolls over, the users will just have to run the files through exiftool again and it should update them accordingly. Not too much of a hassle, better than the solution I was testing which invloved adding the right timezone based on how the users' computers are set to.

Thanks again,

Justin.

[Phil Harvey]

Justin,

Windows doesn't actually change the FileModifyDate when you change the time zone. You're thinking backwards here.  The time actually stays the same.  1pm in New York is the same time as 10am in Los Angeles.  The times are all stored in GMT on the disk, and the system converts them to your local time zone for display only.

- Phil