[
https://issues.apache.org/jira/browse/LUCENE-6302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14338563#comment-14338563
]
Itamar Syn-Hershko commented on LUCENE-6302:
--------------------------------------------
I actually expected the main objection would be to adding date parsing methods
:)
Maybe it would make sense to explain the use cases this is trying to solve.
We are using Elasticsearch & Kibana and since the latest version switched to
using Lucene Expressions (from Groovy) we found ourselves blocked by the things
we can do with Kibana's scripted fields
For example, given a user's DOB, how can we do aggregations on their age? or
compute how many years (or days) have passed between 2 given days?
Yes we can subtract the epochs (except that it doesn't seem to work
https://github.com/elasticsearch/elasticsearch/issues/9884) but translating the
result to terms of days, hours or years is even uglier using an expression.
I think introducing ValueSources to do this should be enough, but if changing
the lexer will be the preferred way I can go and do that as well. With regards
to syntax - I'm not locked on any preferred syntax.
Either way it seems like adding a now() function is the easiest change and can
send a PR with this change alone to start with.
> Adding Date Math support to Lucene Expressions module
> -----------------------------------------------------
>
> Key: LUCENE-6302
> URL: https://issues.apache.org/jira/browse/LUCENE-6302
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/expressions
> Affects Versions: 4.10.3
> Reporter: Itamar Syn-Hershko
>
> Lucene Expressions are great, but they don't allow for date math. More
> specifically, they don't allow to infer date parts from a numeric
> representation of a date stamp, nor they allow to parse strings
> representations to dates.
> Some of the features requested here easy to implement via ValueSource
> implementation (and potentially minor changes to the lexer definition) , some
> are more involved. I'll be happy if we could get half of those in, and will
> be happy to work on a PR for the parts we can agree on.
> The items we will be happy to have:
> - A now() function (with or without TZ support) to return a current long
> date/time value as numeric, that we could use against indexed datetime fields
> (which are infact numerics)
> - Parsing methods - to allow to express datetime as strings, and / or read it
> from stored fields and parse it from there. Parse errors would render a value
> of zero.
> - Given a numeric value, allow to specify it is a date value and then infer
> date parts - e.g. Date(1424963520).Year == 2015, or Date(now()) -
> Date(1424963520).Year. Basically methods which return numerics but internally
> create and use Date objects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
