-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
[Java.time] Calculate week of a year with ISO rules #48209
Conversation
This reverts commit 8d1ea86.
Introducing a IsoLocal.ROOT constant which should be used instead of java.util.Locale.ROOT in ES when dealing with dates. IsoLocal.ROOT customises start of the week to be Monday instead of Sunday. closes elastic#42588 an issue with investigation details relates elastic#41670 bug raised (this won't fix it on its own. joda.parseInto has to be reimplemented closes elastic#43275 an issue raised by community member change skip reason compile error not orking spi working unit test cleanup change providers for 9+ revert changes IsoLocale cleanup move spi files to server make unit test pass from gradle expermienting with gradle tasks uncomment jar hell check only add settings in buildplugin allign options for locale providers
Pinging @elastic/es-core-infra (:Core/Infra/Core) |
I think this should be merged to v8 and v7.6. We still support jdk8 in ESv7 and this approach won't work (unless |
During the SQL team meeting we decided to keep the current implementation of date functions as they are. However I think they need to be fixed too as I found some problems there. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@@ -857,6 +857,8 @@ class BuildPlugin implements Plugin<Project> { | |||
'tests.security.manager': 'true', | |||
'jna.nosys': 'true' | |||
|
|||
test.systemProperty ('java.locale.providers','SPI,COMPAT') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please add a comment that this won't be needed once we include jvm.options in tests sysprops?
In #48209 PR unused import and redundant else statements were missed. This commit cleans this up
} | ||
|
||
public void testLogExpirationWarningOnJdk8() { | ||
public void testLogExpirationWarning() { | ||
assumeTrue("this is for JDK8 only", JavaVersion.current().equals(JavaVersion.parse("8"))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pgomulka I think this part of the change might have been incorrect...
We collapsed the 2 tests into 1, but that one test is set to only run on JDK8. I think this assumeTrue
should be removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tvernum you are right, the same applies to 7.x branch as the output should be the same.
thanks for taking a look!
Some extended testing with MS-SQL server and H2 (which agree on results) revealed bugs in the implementation of WEEK related extraction and diff functions. Non-iso WEEK seems to be broken since elastic#48209 because of the replacement of Calendar and the change in the ISO rules. ISO_WEEK failed for some edge cases around the January 1st. DATE_DIFF was previously based on non-iso WEEK extraction which seems not to be the case. Fixes: elastic#49376
This test no longer relies on jdk version, so the assume should be removed relates #48209
This test no longer relies on jdk version, so the assume should be removed relates elastic#48209
This test no longer relies on jdk version, so the assume should be removed relates #48209
Some extended testing with MS-SQL server and H2 (which agree on results) revealed bugs in the implementation of WEEK related extraction and diff functions. Non-iso WEEK seems to be broken since #48209 because of the replacement of Calendar and the change in the ISO rules. ISO_WEEK failed for some edge cases around the January 1st. DATE_DIFF was previously based on non-iso WEEK extraction which seems not to be the case. Fixes: #49376
Some extended testing with MS-SQL server and H2 (which agree on results) revealed bugs in the implementation of WEEK related extraction and diff functions. Non-iso WEEK seems to be broken since #48209 because of the replacement of Calendar and the change in the ISO rules. ISO_WEEK failed for some edge cases around the January 1st. DATE_DIFF was previously based on non-iso WEEK extraction which seems not to be the case. Fixes: #49376 (cherry picked from commit 54fe7f5)
Some extended testing with MS-SQL server and H2 (which agree on results) revealed bugs in the implementation of WEEK related extraction and diff functions. Non-iso WEEK seems to be broken since #48209 because of the replacement of Calendar and the change in the ISO rules. ISO_WEEK failed for some edge cases around the January 1st. DATE_DIFF was previously based on non-iso WEEK extraction which seems not to be the case. Fixes: #49376 (cherry picked from commit 54fe7f5)
Some extended testing with MS-SQL server and H2 (which agree on results) revealed bugs in the implementation of WEEK related extraction and diff functions. Non-iso WEEK seems to be broken since #48209 because of the replacement of Calendar and the change in the ISO rules. ISO_WEEK failed for some edge cases around the January 1st. DATE_DIFF was previously based on non-iso WEEK extraction which seems not to be the case. Fixes: #49376 (cherry picked from commit 54fe7f5)
Some extended testing with MS-SQL server and H2 (which agree on results) revealed bugs in the implementation of WEEK related extraction and diff functions. Non-iso WEEK seems to be broken since elastic#48209 because of the replacement of Calendar and the change in the ISO rules. ISO_WEEK failed for some edge cases around the January 1st. DATE_DIFF was previously based on non-iso WEEK extraction which seems not to be the case. Fixes: elastic#49376
IsoLocale - a class introduced to configure start of the week as Monday (with the use of extension) does not allow to configure minimum number of days in a first week. This does not allow correctly calculate week of a week-based-year with ISO rules.
ISO rule is: First day of a week is Monday AND minimum number of days in a first week of a year is 4.
This change is to refactor this with the use of CalendarDataProvider and requires a jvm property java.locale.providers to be set with SPI,COMPAT. SPI is for this change, COMPAT was already used to be compatible with JDK8 date behaviour.
Previously not all tests were using COMPAT, so had to be changed now (notice the change in how dates are represented without
.
in text forms)SQL plugin is at the moment configured to use
SUNDAY
rule - meaning First of the week is Sunday and requires only 1 day in a week to be the first week of the year. This was discussed with SQL team, to keep non-iso functions rely on Sunday,1 rule. cc @astefanA link to consider https://docs.microsoft.com/en-us/sql/t-sql/functions/datepart-transact-sql?view=sql-server-ver15#week-and-weekday-datepart-arguments
closes #41670 a bug raised where week is wrongly calculated
relates #43652 the previous attempt to just change start of the week
relates #42588 an issue with investigation details
relates #43275 a bug related to week starting on SUNDAY (fixed by #43652 but also by this PR)