Datetime should expose the underlying concept unresolved and not just the resolution with respect to today

[chrimc62]

Is your feature request related to a problem? Please describe.
Imagine a query like: "leave July 15th and come back the next Monday"
You should get two timex, i.e. XXXX-06-15 and a representation of the concept of "next monday". That allows the consumer to decide how to combine the time. It is important to represent the actual concept since this could also be a conversation like:

User: Leave july 15th
Bot: When do you want to come back?
User: next monday

In this case we want next monday to be a TIMEX that can be combined with the background anchor point. Today "next monday" is always resolved wrt the current date and there is no way to distinguish between an actual date and "next monday".

This applies to other kinds of expressions as well like the first monday of july--that should not resolve to a particular monday.

Describe the solution you'd like
Explicitly represent date time expressions. This could be in addition to concrete resolutions with respect to today.

[tellarin]

This is not how the system currently works. Every utterance is interpreted based on an anchor date parameter. Only if the anchor date is omitted, then ‘today’ is used as context. So the multi-turn behaviour above can already be implemented.
Individual terms in the same sentence could also be re-parsed with new context.

Having said that, yes, all timexes should be re-resolvable with a new anchor date. Unfortunately in the current implementation (due to old design decisions) some timexes lose generality and this is not always possible.

As changing the timexes is a breaking change, the current goal is to introduce an additional gen-timex (the generalised one) attribute and in a future v2 release make the switch (and drop the non-general timexes).