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.
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.
OptionalasyncTimeout in milliseconds for asynchronous disposal (using Symbol.asyncDispose). If graceful cleanup takes longer than this, forceful cleanup is attempted.
Should 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.
Should we check for a readable and executable perl file in $PATH? Set
this to false if you know perl is installed.
Should batch-cluster try to clean up after spawned processes that don't shut down?
Only disable this if you have another means of PID cleanup.
Defaults to true.
Video file dates are assumed to be in UTC, rather than using timezone
inference used in images. To disable this default, set this to false.
OptionaldisposalTimeout in milliseconds for synchronous disposal (using Symbol.dispose). If graceful cleanup takes longer than this, forceful cleanup is attempted.
When this.end() is called, or Node broadcasts the beforeExit event,
this is the milliseconds spent waiting for currently running tasks to
finish before sending kill signals to child processes.
Setting this value to 0 means child processes will immediately receive a kill signal to shut down. Any pending requests may be interrupted. Must be >= 0. Defaults to 500ms.
Args only passed to exiftool on launch. You probably don't need to change this from the default.
Environment variables passed to ExifTool (besides EXIFTOOL_HOME)
Allows for non-standard paths to ExifTool.
This must be the full path to exiftool, not just the directory.
OptionalexitCommand to end the child batch process. If not provided (or undefined),
stdin will be closed to signal to the child process that it may terminate,
and if it does not shut down within endGracefulWaitTimeMillis, it will be
SIGHUP'ed.
Expected text to print if a command fails. Cannot be blank. Strings will be interpreted as a regular expression fragment.
When writing an extracted tag to a file, this will overwrite an existing
file instead of throwing an error. Enabling this option is equivalent to
-w! in ExifTool.
When reading metadata, should we enable ExifTool's geolocation features? Note that this requires ExifTool version 12.78 or later.
Override the default geo-to-timezone lookup service. Note that if geolocation is enabled, we'll use Tags.GeolocationTimeZone if it's not blank.
If your implementation throws an error, ExifTool will consider that
given latitude/longitude as invalid.
OptionalhealthIf provided, and healthCheckIntervalMillis is greater than 0, or the previous task failed, this command will be sent to child processes.
If the command outputs to stderr or returns a fail string, the process will be considered unhealthy and recycled.
If healthCheckCommand is set, how frequently should we check for
unhealthy child processes?
Set this to 0 to disable this feature.
Should we ignore minor errors when reading metadata?
ExifTool has a shebang line that assumes a valid perl is installed at
/usr/bin/perl.
Some environments may not include a valid /usr/bin/perl (like AWS
Lambda), but perl may be available in your PATH some place else (like
/opt/bin/perl), if you pull in a perl layer.
Note that when enabled, perl will be spawned in a sub-shell.
Some 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.
If 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.
We 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 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.
Some 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.
Should ExifTool keep times that are stored as seconds since UTC epoch as
UTC times? If false, ExifTool will use local time instead of UTC/Zulu.
Note: when trying to validate this option, we could not find a single example that had a unixtime-encoded datetime, so this is likely irrelevant for most use cases and files.
A BatchCluster instance and associated BatchProcess instances will share
this Logger. Defaults to the Logger instance provided to setLogger().
How many failed tasks should a process be allowed to process before it is recycled?
Set this to 0 to disable this feature.
If a child process is idle for more than this value (in milliseconds), shut it down to reduce system resource consumption.
A value of ~10 seconds to a couple minutes would be reasonable. Set this to 0 to disable this feature.
Child processes will be recycled when they reach this age.
If non-zero, this value must not be less than spawnTimeoutMillis or
taskTimeoutMillis.
Defaults to 5 minutes. Set to 0 to disable.
The maximum number of ExifTool child processes to spawn when load merits.
The maximum number of requests a given ExifTool process will service before being retired.
If maxProcs > 1, spawning new child processes to process tasks can slow down initial processing, and create unnecessary processes.
Must be >= 0ms. Defaults to 1.5 seconds.
Tag 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.
An interval timer is scheduled to do periodic maintenance of underlying child processes with this periodicity.
Expected text to print if a command passes. Cannot be blank. Strings will be interpreted as a regular expression fragment.
Verify child processes are still running by checking the OS process table.
Set this to 0 to disable this feature.
Timezone 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 in incorrect timezones.
ReadonlyprocessFactory function to spawn child processes.
CRITICAL: If you spawn a child process and then reject the promise, YOU are responsible for killing the spawned process. BatchCluster cannot track processes that were never returned.
Safe pattern:
async function myFactory(): Promise<ChildProcess> {
const proc = spawn("my-command", args);
try {
await someValidation(proc);
return proc;
} catch (error) {
proc.kill(); // REQUIRED: Clean up before rejecting!
throw error;
}
}
Unsafe pattern (LEAKS PROCESSES):
async function leakyFactory(): Promise<ChildProcess> {
const proc = spawn("my-command", args);
await someValidation(proc); // If this throws, proc is orphaned!
return proc;
}
Any 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
ExifTool.read.
Spawning new ExifTool processes must not take longer than this before the child process is timed out and a new attempt is made. Be pessimistic here--windows can regularly take several seconds to spin up a process, thanks to antivirus shenanigans. This can't be set to a value less than 100ms.
When a task sees a "pass" or "fail" from either stdout or stderr, it needs to wait for the other stream to finish flushing to ensure the task's Parser sees the entire relevant stream contents. A larger number may be required for slower computers to prevent internal errors due to lack of stream coercion.
Note that this puts a hard lower limit on task latency, so don't set this to a large number: no task will resolve faster than this value (in millis).
If you set this value too low, tasks may be erroneously resolved or rejected (depending on which stream is handled first).
Your system may support a smaller value: this is a pessimistic default. If
this is set too low, you'll see noTaskData events.
Setting this to 0 makes whatever flushes first--stdout and stderr--and will most likely result in internal errors (due to stream buffers not being able to be associated to tasks that were just settled)
How should ExifTool handle nested structures?
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 copyingThe number of times a task can error or timeout and be retried.
If requests to ExifTool take longer than this, presume the underlying
process is dead and we should restart the task. This can't be set to a
value less than 10ms, and really should be set to at more than a second
unless taskRetries is sufficiently large or all writes will be to a
fast local disk.
Should ExifTool use MWG (Metadata Working Group) composite tags for reading and writing tags?
ExifTool recommends this to be set to true. 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
Low-overhead command to verify the child batch process has started correctly. This "startup command" is invoked immediately after spawn, and must complete successfully before any user tasks are assigned to the process.
Typically this runs a version check (like -ver for ExifTool), hence the
name. The command should be fast and reliable.
If this command fails or times out (per BatchClusterOptions.spawnTimeoutMillis), the process is considered broken and will be terminated.
Any additional arguments that should be added by default to all write
tasks, like ["-overwrite_original"]. The value provided to the ExifTool
constructor can be overridden in the call to ExifTool.write.
Options for the ExifTool constructor.
Defaults are defined in DefaultExifToolOptions.
See