Date Handling
Since TIKA-4917 in 4.2.0, one parser in tika-core, org.apache.tika.utils.TikaDates, parses
every date string a document supplies. It replaced three parsers with different rules
(DateUtils, MailDateParser, and the XMP path), which had stamped some zone-less values with
Z, resolved others in the server’s time zone, and inflated partial or invalid dates into
full timestamps. Dates now depend only on what the document says.
Storage forms
A DATE-typed metadata value takes one of three shapes:
| Document says | Stored as | Example |
|---|---|---|
Zone or offset |
Canonical UTC |
|
Wall clock, no zone |
Zone-less |
|
Date only |
Date only |
|
Partial dates (2019, 2019-06) and values Tika cannot parse stay on the format’s own key
(for example xmpDM:releaseDate) and are never promoted to dcterms:created or
dcterms:modified. Years outside 1000..2200 are rejected.
Reading dates back
Metadata.getDate() reads a zone-less value as UTC, never as the JVM default zone, and a
date-only value as midday UTC. Partial and out-of-range values return null.
Endpoints that require a full timestamp (Solr pdate, for example) still need the
date-normalizing-metadata-filter. It resolves
zone-less and date-only values in a configured default zone, and it invents the missing
fields of a partial date: 2019 becomes January 1, 2019-06 becomes June 1, both at midday.
Tika itself never does this; only the filter does, and only because a rejected date field
would otherwise reject the whole document.