Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[EN|ES|PT|CN DateTimeV2] Relative ranges in a year not always correctly recognized (#2651) #2770

Merged
merged 3 commits into from Dec 7, 2021

Conversation

aitelint
Copy link
Contributor

Fix to issue #2651 in EN, ES, PT.

Solution not yet implemented in CN.

Test cases added to DateTimeModels.

@aitelint
Copy link
Contributor Author

fix implemented in CN too

@aitelint aitelint changed the title [EN|ES|PT DateTimeV2] Relative ranges in a year not always correctly recognized (#2651) [EN|ES|PT|CN DateTimeV2] Relative ranges in a year not always correctly recognized (#2651) Nov 19, 2021

var month = this.config.MonthOfYear[monthStr];
var month = match.Groups["month"].Success ? this.config.MonthOfYear[monthStr] :
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a code comment here to make it easier to understand?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added

@@ -1732,6 +1734,49 @@ private DateTimeResolutionResult ParseDuration(string text, DateObject reference
endDate = modAndDateResult.EndDate;
}

// Handle cases like "first 2 weeks of 2019", "last 3 months of this year"
var matchBefore = this.config.FirstLastRegex.Match(beforeStr);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any kind of "pre-check" that can happen here to avoid applying both regexes always to parsing? Or is this already nested somewhere that isn't called frequently?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

now the 2 checks are nested

@@ -291,6 +296,63 @@ public int GetYearFromText(Match match)
return year;
}

private static DateObject GetFirstThursday(int year, int month = Constants.InvalidMonth)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shoudn't these two methods be in a common palce that can be called everywhere? The calculations are not CJK specific.
Maybe this should be in some utility in the timexlib?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

moved to DateObjectExtension

@@ -6651,5 +6651,205 @@
}
}
]
},
{
"Input": "Created On 是在 2021年的第一周",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do they start in English? :)
One example for code switching is OK, but it would be better if the others were fully in Chinese, and more diverse in sentence form.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, test cases modified

]
},
{
"Input": "Created On is in the second week of 2021",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Desirable: It would be great if new specs have more variety in sentence structure than just repeating the base sentence and changing the mention form. Same in other languages.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

modified inputs

@tellarin
Copy link
Collaborator

tellarin commented Dec 7, 2021

@aitelint Looks mostly good. Can you validate it still works and resolve the minor conflict? Thanks!

@aitelint
Copy link
Contributor Author

aitelint commented Dec 7, 2021

still working, conflicts solved

@tellarin tellarin merged commit 56ab87f into microsoft:master Dec 7, 2021
@aitelint aitelint deleted the #2651 branch December 7, 2021 07:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants