[Python TimexLib] Inconsistency in weekday resolution between TimexLib and LUIS
Describe the bug Inconsistency in weekday resolution between TimexLib and LUIS.
To Reproduce Steps to reproduce the behavior:
- Try asking the timex weekday of the same day as today
- E.g., Ask Monday in LUIS and TimexLib(Python) to figure out 'XXXX-WXX-1' on Monday
- Differences between LUIS and TimexLib(Python)
Python datatypes-timex-expression>=1.0.2a2
from datetime import datetime
from datatypes_timex_expression import TimexResolver, Resolution
timex = 'XXXX-WXX-1'
today = datetime.today()
resolution = TimexResolver.resolve([timex], today)
resolution.values[0].__dict__
Out[13]:
{'timex': 'XXXX-WXX-1',
'type': 'date',
'value': '2021-11-01',
'start': None,
'end': None}
resolution.values[1].__dict__
Out[14]:
{'timex': 'XXXX-WXX-1',
'type': 'date',
'value': '2021-11-15',
'start': None,
'end': None}
LUIS
"entities": {
"datetimeV2": [
{
"type": "date",
"values": [
{
"timex": "XXXX-WXX-1",
"resolution": [
{
"value": "2021-11-01"
},
{
"value": "2021-11-08"
}
]
}
]
}
],
"$instance": {
"datetimeV2": [
{
"type": "builtin.datetimeV2.date",
"text": "monday",
"startIndex": 0,
"length": 6,
"modelTypeId": 2,
"modelType": "Prebuilt Entity Extractor",
"recognitionSources": [
"model"
]
}
]
}
Expected behavior Trying to establish what's the correct behaviour. Is it today (Monday) or last week's Monday or next week's Monday ? This is applicable to other weekdays as well.
Sample input/output Ask Monday in LUIS and TimexLib(Python) to figure out 'XXXX-WXX-1' on Monday
Platform (please complete the following information):
- Platform: Python vs LUIS
- Environment: console
- Version of package: 1.0.2a2
Additional context Add any other context about the problem here.
I checked this in both .NET and Python as well as in LUIS and the behavior seems to be consistent, I tried the weekday today as well as several weekdays and i am getting a consistent output
All other weekdays work except the checking day is same as that weekday. I'm currently reporting only if you're checking for the weekday same as the day you're checking. Here are few examples you could try,
- On Monday, check for 'XXXX-WXX-1' resolution in python datatypes-timex-expression. Compare that results with the text 'Monday' in LUIS
- On Tuesday, check for 'XXXX-WXX-2' resolution in python datatypes-timex-expression. Compare that results with the text 'Tuesday' in LUIS (It was Tuesday when I left this comment, so checked for this case)
- On Wednesday, check for 'XXXX-WXX-3' resolution in python datatypes-timex-expression. Compare that results with the text 'Wednesday' in LUIS etc..
I tried Tuesday (today) and i am getting this in LUIS "datetimeV2": [ { "type": "date", "values": [ { "timex": "XXXX-WXX-2", "resolution": [ { "value": "2021-11-02" }, { "value": "2021-11-09" } ] } ] } ],
and this in the recognizers { "start": 0, "end": 6, "resolution": { "values": [ { "timex": "XXXX-WXX-2", "type": "date", "value": "2021-11-02" }, { "timex": "XXXX-WXX-2", "type": "date", "value": "2021-11-09" } ] }, "text": "tuesday", "type_name": "datetimeV2.date" }
i am also getting similar results for Monday and Wednesday, I am getting 8/15 and 3/10
it might be on Monday the 1st that is causing an issue that had Monday produce 1/15
When I check in Python using datatypes-timex-expression==1.0.2.a2 it is similar to what I mentioned in the issue description,
from datatypes_timex_expression import TimexResolver
from datetime import datetime
today = datetime.today()
timex = 'XXXX-WXX-2'
resolution = TimexResolver.resolve([timex], today)
resolution.values
Out[8]:
[<datatypes_timex_expression.resolution.Entry at 0x7fea8ed9eca0>,
<datatypes_timex_expression.resolution.Entry at 0x7fea8ed9e880>]
resolution.values[0].__dict__
Out[9]:
{'timex': 'XXXX-WXX-2',
'type': 'date',
'value': '2021-11-02',
'start': None,
'end': None}
resolution.values[1].__dict__
Out[10]:
{'timex': 'XXXX-WXX-2',
'type': 'date',
'value': '2021-11-16',
'start': None,
'end': None}
The .NET results are the canonical ones. Python should match them.
@nikhilkandur the results you are seeing are in version 1.0.2a2 which is dated in 11/2019, this is fixed in the current versions. We should be releasing a version to python soon that should resolve this