[ 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org