You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Datetime should expose the underlying concept unresolved and not just the resolution with respect to today #2448
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.
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.
Having said that, 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 a gen-timex (the generalised one) and in a future v2 release make the switch.
Activity
tellarin commentedon Jan 23, 2021
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.
Having said that, 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 a gen-timex (the generalised one) and in a future v2 release make the switch.