ConstReadonlyadjustReadonlybackfillShould we try to backfill timezones for date-times that don't have them?
If set to true, and defaultVideosToUTC is also true, we'll
try backfilling timezones for date-times that are UTC, as well.
Setting this to false removes all timezone inference--only those
date-times with an explicit offset will have a defined timezone.
Prior versions of exiftool-vendored would use the file's .tz as a
backstop even if this was set to false.
As of version 23, this now defaults to true, as it's more likely to be
what people expect.
ReadonlydefaultVideo file dates are assumed to be in UTC, rather than using timezone inference used in images. To disable this default, set this to false.
Readonlygeolocation: booleanWhen reading metadata, should we enable ExifTool's geolocation features? Note that this requires ExifTool version 12.78 or later.
ReadonlygeoOverride the default geo-to-timezone lookup service. Note that if geolocation is enabled, we'll use Tags.GeolocationTimeZone if it's not blank.
This defaults to @photostructure/tz-lookup, but if you have the
resources, consider using geo-tz for more accurate results.
If your implementation throws an error, ExifTool will consider that given
latitude/longitude as invalid.
Here's a snippet of how to use geo-tz instead of tz-lookup:
const geotz = require("geo-tz")
const { ExifTool } = require("exiftool-vendored")
const exiftool = new ExifTool({ geoTz: (lat, lon) => geotz.find(lat, lon)[0] })
ReadonlyignoreShould we ignore minor errors when reading metadata?
This defaults to true, as ExifTool can be quite chatty.
ReadonlyignoreSome software uses a GPS position of (0,0) as a synonym for "unset". If this option is true, and GPSLatitude and GPSLongitude are both 0, then those values will be returned, but the TZ will not be inferred from that location.
If both this and geolocation are true, we will delete the
Geolocation tags from the returned metadata object.
ReadonlyimageIf defined, ExifTool will attempt to calculate an "ImageDataHash" tag value with a checksum of image data.
Note that as of 2022-04-12, ExifTool supports JPEG, TIFF, PNG, CRW, CR3, MRW, RAF, X3F, IIQ, JP2, JXL, HEIC and AVIF images, MOV/MP4 videos, and some RIFF-based files such as AVI, WAV and WEBP.
This defaults to undefined, as it adds ~20ms of overhead to every read
ReadonlyincludeReadonlyinferWe always look at Tags.TimeZone, Tags.OffsetTime, Tags.TimeZoneOffset, Tags.OffsetTimeOriginal, Tags.OffsetTimeDigitized, and GPS metadata to infer the timezone.
If these strategies fail, and this is enabled, we'll try to infer the timezone from non-UTC datestamps included in the inferTimezoneFromDatestampTags value.
This defaults to false as it both retains prior behavior and means fewer "fuzzy" heuristics are enabled by default.
ReadonlyinferThis is the list of tag names that will be used to infer the timezone as a backstop, if no explicit timezone is found in metadata. Note that datestamps with UTC offsets are ignored, as they are frequently incorrectly set.
This setting is only in play if inferTimezoneFromDatestamps has
been overridden to be true.
This defaults to CapturedAtTagNames
ReadonlyinferSome cameras (Samsung Galaxy S7, for example) may not always include GPS metadata in photos if a fix can't be obtained. If this option is true, and GPS metadata is missing, we'll try to infer the timezone from the difference of the TimeStamp tag and the first defined tag value from inferTimezoneFromDatestampTags.
This heuristic is pretty sketchy, and used as a last resort. You shouldn't enable it unless you have to.
ReadonlynumericTag names (which can have '*' glob matchers) which you want numeric values, rather than ExifTool's "Print Conversion."
If you're using tag values only for human consumption, you may want to leave this blank.
The default includes "Duration", Tags.GPSAltitude, Tags.GPSLatitude, Tags.GPSLongitude, Tags.GPSPosition, and Tags.Orientation.
ReadonlypreferTimezone parsing requires a bunch of heuristics due to hardware and software companies not following metadata specifications similarly.
If GPS metadata is trustworthy, set this to true to override explicit
values assigned to TimezoneOffsetTagnames.
Note that there are regions that have had their IANA timezone change over time--this will result incorrect timezones.
ReadonlyreadAny additional arguments that should be added by default to all read tasks,
like ["-fast", "-api", "largefilesupport=1"]. The value provided to the
ExifTool constructor can be overridden in the call to ()
Readonlystruct: How should ExifTool handle nested structures?
Defaults to 1.
0 = Read/copy flattened tags1 = Read/copy structures2 = Read/copy both flattened and structured tags, but flag flattened
tags as "unsafe" for copying"undef" = Same as 0 for reading and 2 for copyingReadonlyuseMWG: booleanShould ExifTool use MWG (Metadata Working Group) composite tags for reading and writing tags?
ExifTool recommends this to be set to true. This defaults to false to
maintain consistency with prior versions.
Note that this can result in many tag value differences from
ExifTool.read, and makes ExifTool.write write to "synonymous" MWG
tags automatically.
https://exiftool.org/TagNames/MWG.html for details
The TimeZone tag normally represents the offset from UTC.
Unfortunately, at least for some Nikon cameras, the TimeZone tag and the DaylightSavings tag must be taken into account to find the UTC offset.
By default, this is a predicate that returns
trueif theMaketag isNikon. If you find other makes and models that need this treatment, please open a ticket on GitHub with example images or videos and we can update the default predicate.The return value is the number of minutes to adjust the timezone by.