metadata-extractor
metadata-extractor copied to clipboard
drewnoakes
Need a way to get the timezone associated with returned Dates
Some contains date/times with a timezones, some without. Users need to be able to query whether a tag contains a timezone or not. Here is a concrete example:
I've got an mp4 file for which exiftool returns:
Content Create Date : 2014:08:05 11:57:19+02:00
I believe this maps to Mp4Directory.TAG_CREATION_TIME but when I query the latter I get a Date with no indication whether it contained a timezone or not (and what the timezone offset was if one exists). This is important because if a timezone is absent I want to treat this time as the "local time" (the time at whatever timezone the photographer was in) and apply a transform to convert it to UTC. But if a timezone was present, then the time is already at UTC.
This is another case where using java.util.ZonedDateTime would be beneficial.
You might want to peruse this thread:
https://github.com/drewnoakes/metadata-extractor/issues/460
In short, the MP4 standard is to record the time in UTC. There is no provision for a time zone. If the device (like a phone) knows what time zone it's in, it will record the time as UTC. If the device doesn't know what time zone it's in (my camera, for example), it will record the time as whatever time the device is currently set to.
Yes, I know - it's almost useless. But that's the decision someone made.
@jefftucker1952 I get your point but then how is exiftool retaining the timezone offset for this tag? If I set the tag to a time with a timezone offset (+02:00) using exiftool then I can get it back with that same offset. If I set it without an offset, I get it back without an offset.
https://github.com/drewnoakes/metadata-extractor/issues/460#issuecomment-576931276 seems to imply the value is stored as UTC as you mentioned, but then where is exiftool getting the timezone from? The timezone in question does not correspond to my local timezone. It corresponds to the timezone that the video was taken in. For example, my local timezone offset is -05:00 but I have a video recorded in Italy with an offset of +02:00.
It sounds like you're setting the tag to a time with an offset. The cameras don't do so, or at least I haven't encountered one that does. The information you need simply isn't in the file's metadata.
One user was reduced to using GPS info to derive the timezone. Now there's a rabbit hole you probably don't want to go down. ;)
@jefftucker1952 Nope. I always set UserComment if I touch metadata and the video I'm looking at does not have it. Here are the tags it does have:
ExifTool Version Number : 12.14
File Name : IMG_2016.mp4
Directory : C:/photos/new/2014/2014-08-Italy.backup.v3/965YOKDJ
File Size : 11 MiB
File Modification Date/Time : 2021:02:03 11:15:45-05:00
File Access Date/Time : 2021:02:07 12:03:31-05:00
File Creation Date/Time : 2021:02:06 19:48:11-05:00
File Permissions : rw-rw-rw-
File Type : MP4
File Type Extension : mp4
MIME Type : video/mp4
Major Brand : MP4 Base Media v1 [IS0 14496-12:2003]
Minor Version : 0.2.0
Compatible Brands : isom, iso2, avc1, mp41
Movie Header Version : 0
Create Date : 2014:08:07 09:16:32
Modify Date : 2014:08:07 09:16:38
Time Scale : 1000
Duration : 5.95 s
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 : 2014:08:07 09:16:32
Track Modify Date : 2014:08:07 09:16:38
Track ID : 1
Track Duration : 5.91 s
Track Layer : 0
Track Volume : 0.00%
Image Width : 1920
Image Height : 1080
Graphics Mode : srcCopy
Op Color : 0 0 0
Compressor ID : avc1
Source Image Width : 1920
Source Image Height : 1080
X Resolution : 72
Y Resolution : 72
Bit Depth : 24
Video Frame Rate : 29.97
Matrix Structure : 1 0 0 0 1 0 0 0 1
Media Header Version : 0
Media Create Date : 2014:08:07 09:16:32
Media Modify Date : 2014:08:07 09:16:38
Media Time Scale : 44100
Media Duration : 5.94 s
Media Language Code : und
Handler Description : Core Media Audio
Balance : 0
Audio Format : mp4a
Audio Channels : 2
Audio Bits Per Sample : 16
Audio Sample Rate : 44100
Handler Vendor ID : Apple
Encoder : Lavf58.45.100
Content Create Date : 2014:08:07 11:16:32+02:00
Software Version : 7.1.2
Handler Type : Metadata Tags
Creation Date : 2014:08:07 11:16:32+02:00
Creation Date (und-CA) : 2014:08:07 11:16:32+02:00
Make (und-CA) : Apple
Model (und-CA) : iPhone 5
Software : 7.1.2
Software (und-CA) : 7.1.2
XMP Toolkit : Image::ExifTool 12.14
Make : Apple
Camera Model Name : iPhone 5
Media Data Size : 11180331
Media Data Offset : 10738
Image Size : 1920x1080
Megapixels : 2.1
Avg Bitrate : 15 Mbps
Rotation : 0
Notice Creation Date and Camera Model Name near the bottom.
I really don't want to go down this "path to madness" again. But the MP4's coming from my very standard Android phone have no TZ offset information in them whatsoever. Nor do the MOV's coming out of my Nikon. If an iPhone does, more power to it. But that's nonstandard.
From a recent video:
ExifTool Version Number : 11.74
File Name : test.mp4
Directory : .
File Size : 74 MB
File Modification Date/Time : 2020:10:13 15:57:10-04:00
File Access Date/Time : 2021:02:07 12:14:08-05:00
File Creation Date/Time : 2021:02:07 12:13:14-05:00
File Permissions : rw-rw-rw-
File Type : MP4
File Type Extension : mp4
MIME Type : video/mp4
Major Brand : MP4 v2 [ISO 14496-14]
Minor Version : 0.0.0
Compatible Brands : isom, mp42
Movie Data Size : 78089610
Movie Data Offset : 32
Movie Header Version : 0
Create Date : 2020:10:13 18:33:50
Modify Date : 2020:10:13 18:33:50
Time Scale : 1000
Duration : 0:00: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
Play Mode : SEQ_PLAY
Android Version : 8.0.0
Track Header Version : 0
Track Create Date : 2020:10:13 18:33:50
Track Modify Date : 2020:10:13 18:33:50
Track ID : 1
Track Duration : 0:00:36
Track Layer : 0
Track Volume : 0.00%
Image Width : 1920
Image Height : 1080
Graphics Mode : srcCopy
Op Color : 0 0 0
Compressor ID : avc1
Source Image Width : 1920
Source Image Height : 1080
X Resolution : 72
Y Resolution : 72
Bit Depth : 24
Pixel Aspect Ratio : 65536:65536
Color Representation : nclx 1 1 1
Video Frame Rate : 29.974
Matrix Structure : 1 0 0 0 1 0 0 0 1
Media Header Version : 0
Media Create Date : 2020:10:13 18:33:50
Media Modify Date : 2020:10:13 18:33:50
Media Time Scale : 48000
Media Duration : 0:00:36
Handler Type : Audio Track
Handler Description : SoundHandle
Balance : 0
Audio Format : mp4a
Audio Channels : 2
Audio Bits Per Sample : 16
Audio Sample Rate : 48000
Image Size : 1920x1080
Megapixels : 2.1
Avg Bitrate : 17.2 Mbps
Rotation : 0
So you're saying that from your perspective, there is no way to figure out whether the timestamp is referring to the local time vs UTC? I agree that the specification says that UTC should be stored but often (especially for older files) the camera had no way of knowing the timezone information for the local time was stored. I'm processing tens of thousands of files. I can't really figure this out on a per-file basis.
Yes, that's the unpleasant truth - there's usually just no way to determine what the Media Creation Time is referring to. Lack of data.
If you're working with the same kinds of files all the time, you can work your way around it. My phone cranks out files with file names that reflect the local recording time, so I can use that. My camera records only whatever time it was set for, so if I remembered to reset it when I got off the plane, the timestamp is good. Otherwise, I'm doomed. ;)
@jefftucker1952 So per https://exiftool.org/forum/index.php?topic=12137.msg65585#msg65585 the tag is stored as a String.
I suggest the following action items:
-
Mp4Directory.getString(Mp4Directory.TAG_CREATION_TIME)should return the raw tag value (as opposed toDate.toString()which it currently returns). That will allow me to easily check for the presence of a timezone. - Clarify whether this library parses for and takes timezone information into consideration when constructing the
Date. I suspect it does but let's clarify this.