Impossible to get correct interval from datetime
michaelmior opened this issue · 13 comments
When I wit returns a datetime entity for a phrase such as
07/11/2018 at 11:00 AM for 60 minutes
I get back an interval datetime from 7/11/2018, 11:00:00 AM to 7/11/2018, 12:00:00 PM.
However, for a phrase such as
07/11/2018 at 11:00 AM - 12:00 PM
These two clearly have the same intended meaning, but for the second, I get back an interval datetime from 7/11/2018, 11:00:00 AM to 7/11/2018, 1:00:00 PM. This means it's currently not possible for my application to handle both of these scenarios. Any help would be appreciated.
Hey @michaelmior, this would be best posted in https://github.com/facebook/duckling/ -- the library that backs our datetime parsing. Maintainers there can decide on what the full fix is there
07/11/2018 at 11:00 AM for 60 minutes returns 11am-12pm.
07/11/2018 at 11:00 AM - 12:00 PM returns 11am-12:01pm.
Fix upcoming to return 11am-12:01pm for both.
This is now fixed.
Could you clarify how each of these is expected to parse now?
See my comment above: both return the interval [11am - 12:01pm[. You can try it out in the Wit UI or on the API to see the output.
Hope this helps.
Sorry, I must have spaced out when I was reading this thread earlier. Thanks!
I am still seeing the second example give me the time interval from 11am-1pm
@michaelmior I cannot reproduce your issue. This is what I'm getting:
Can you confirm this is fixed for you?
Hmm, the specific examples I mentioned in the issue are fixed, but others are still broken
today from 9pm for 60 minutes
gives what I would expect, 9-10:01pm
today from 9-10pm
gives 9-11pm
"today from 9-10pm" -> [9pm-11pm[
This is expected. The upper bound is exclusive and the grain (granularity) here is "hour", which means that the inclusive notation would be [9pm-10pm]. In other words, you need to subtract the grain unit from the upper bound.
"9-10:01pm" has a granularity minute, but the same logic applies.
Okay, I'll check the granularity as this may solve my problem. Thanks!
Looking at the granularity does indeed solve the problem :)
Glad to hear, thank you for your feedback @michaelmior!