[
https://issues.apache.org/jira/browse/SOLR-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-750.
---------------------------
Resolution: Invalid
Solr does have timezone support: it supports UTC ... that may sound like a
cop-out answer, but it's true. DateField specifies that it only accepts UTC
formated dates, and stores the UTC date in the index, it knows that a date it
receives as input is UTC because it ends in "Z"
In the future, DateField might start allowing documents to be indexed with
alternate timezone specifiers, and convert to UTC internally before writing to
the index; or new options might get added at some point to allow query clients
to specify what timezone they are in, and solr could convert all the internal
dates to that timezone for them, etc...
...if/when features like those get implemented, they can only work if there is
a standardized internal format, and at hte moment the only way DateField can
ensure that there is a standardized internal format is if it forces the clients
updating the index to only send UTC dates.
bq. If I'm using Solr and want to feed it dates in a particular time zone, or
perhaps a local-time of day, and clients expect this, then why should Solr
force me to specify a timezone? I find it irritating.
there's nothing to stop you from lying to solr about the timezone. If all of
the update/search clinets for your instance are in on the secret that the times
are really GMT-0730 even though solr thinks they are UTC, then no one gets hurt.
But if we droped the requirement that date inputs have the "Z" suffix, people
would assume they can index stuff like 1995-12-31T23:59:59-07:30 and then be
confused when it doesn't work.
> DateField.parseMath doesn't handle non-existent Z
> -------------------------------------------------
>
> Key: SOLR-750
> URL: https://issues.apache.org/jira/browse/SOLR-750
> Project: Solr
> Issue Type: Bug
> Affects Versions: 1.3
> Reporter: David Smiley
> Priority: Minor
> Attachments: SOLR-750_DateField_no_Z.patch
>
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> I've run into situations when trying to use SOLR-540 (wildcard highlight
> spec) such that if attempts to highlight a date field, I get a stack trace
> from DateField.parseMath puking because there isn't a "Z" at the end of an
> otherwise good date-time string. It was very easy to fix the code to make it
> react gracefully to no Z. Attached is the patch. This bug isn't really
> related to SOLR-540 so please apply it without waiting for 540.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
