[
https://issues.apache.org/jira/browse/TIKA-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17386415#comment-17386415
]
Tim Allison commented on TIKA-3496:
-----------------------------------
My current preference would be to store the Property in the Metadata object so
that at emit time, we could determine if the value is supposed to be a date.
I don't want to run afoul of the point of that JPEG comment, and I don't want
to deal with figuring out what the emit-target thinks the date is...
The other issue is that even if it were right to fix the issue in the JPEG
parser, we'll probably have this issue in other parsers currently in new
parsers in the future.
> Dates should have a timezone?
> -----------------------------
>
> Key: TIKA-3496
> URL: https://issues.apache.org/jira/browse/TIKA-3496
> Project: Tika
> Issue Type: Bug
> Reporter: Tim Allison
> Priority: Major
>
> In working on the Solr pipe emitter, I noticed that some dates as stored in
> our Metadata do not have a timezone, which causes a problem for Solr.
> I noticed this issue in a JPEG with date: "2011-06-11T09:30:54".
> In a comment in our JPEG parser, I see:
> {noformat}
> // Unless we have GPS time we don't know the time zone so date must be set
> // as ISO 8601 datetime without timezone suffix (no Z or +/-)
> {noformat}
> So, the question is should we try to add a timezone (arbitrarily assign 'Z')
> in the Solr (and OpenSearch) emitter or should we store the date as if it
> were Z in the JPEG parser?
> Or do something else?
> The challenge with doing anything on the emitter side, is that we aren't
> currently storing the property type in the metadata. So, at emit time, we
> only have string keys and string values. We can't easily guess which fields
> should be a date in order to reformat for the sake of Solr. We could make a
> request to Solr/OpenSearch to figure out what the field types are, but that
> seems really awful...
> Ideas?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
