Week based parsing for ingest date processor #58597
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Date processor was incorrectly parsing week based dates as when a weekbased year was provided ingest module was thinking year was not on a date and was trying to applying the logic for `dd/MM` type of dates. For testing ingest has to have access to ISOCalendarDataProvider in order to correctly calculate week based dates with ISO rules. Date Processor is also allowing users to specify locale parameter. It should be taken into account when parsing dates - currently only used for formatting. If someone specifies 'en-us' locale, then calendar data rules for that locale should be used. closes elastic#58479
pgomulka
added
:Core/Infra/Core
Collaborator
|
Pinging @elastic/es-core-infra (:Core/Infra/Core) |
rjernst
reviewed
Jun 29, 2020
| Function<String, ZonedDateTime> getFunction(String format, ZoneId timezone, Locale locale) { | ||
| return (date) -> DateFormatters.from(DateFormatter.forPattern("iso8601").parse(date), timezone) | ||
| .withZoneSameInstant(timezone); | ||
| // |
| assertThat(DateFormat.fromString("tai64n"), equalTo(DateFormat.Java)); | ||
| assertThat(DateFormat.fromString("prefix-" + randomAlphaOfLengthBetween(1, 10)), equalTo(DateFormat.Java)); | ||
| } | ||
|
|
modules/ingest-common/build.gradle
Outdated
|
|
||
| dependencies { | ||
| compileOnly project(':modules:lang-painless') | ||
| compile project(':libs:elasticsearch-core') |
Member
There was a problem hiding this comment.
Why is this necessary? modules depend on server, implicitly, so we should be able to use the date classes moved there from server, not need them in core lib
Contributor
Author
There was a problem hiding this comment.
I had problem accessing IsoCalendarDataProvider from server when running ingest yml tests.
Maybe adding this as test only? But then again it has to be available when running a cluster for yml test.
Any ideas?
Contributor
Author
There was a problem hiding this comment.
interesting. I cannot reproduce that failure now. I can see from dependency tree that server is indeed on a test compile classpath. Not sure how was this failing for me before..
Reverted back the change moving IsoCalendarDataProvider
pgomulka
added a commit
to pgomulka/elasticsearch
that referenced
this pull request
Jul 1, 2020
Date processor was incorrectly parsing week based dates because when a weekbased year was provided ingest module was thinking year was not on a date and was trying to applying the logic for dd/MM type of dates. Date Processor is also allowing users to specify locale parameter. It should be taken into account when parsing dates - currently only used for formatting. If someone specifies 'en-us' locale, then calendar data rules for that locale should be used. The exception is iso8601 format. If someone is using that format, then locale should not override calendar data rules. closes elastic#58479 # Conflicts: # server/src/main/java/org/elasticsearch/common/time/DateFormatters.java
pgomulka
added a commit
to pgomulka/elasticsearch
that referenced
this pull request
Jul 1, 2020
Date processor was incorrectly parsing week based dates because when a weekbased year was provided ingest module was thinking year was not on a date and was trying to applying the logic for dd/MM type of dates. Date Processor is also allowing users to specify locale parameter. It should be taken into account when parsing dates - currently only used for formatting. If someone specifies 'en-us' locale, then calendar data rules for that locale should be used. The exception is iso8601 format. If someone is using that format, then locale should not override calendar data rules. closes elastic#58479 # Conflicts: # server/src/main/java/org/elasticsearch/common/time/DateFormatters.java
pgomulka
added a commit
to pgomulka/elasticsearch
that referenced
this pull request
Jul 1, 2020
Date processor was incorrectly parsing week based dates because when a weekbased year was provided ingest module was thinking year was not on a date and was trying to applying the logic for dd/MM type of dates. Date Processor is also allowing users to specify locale parameter. It should be taken into account when parsing dates - currently only used for formatting. If someone specifies 'en-us' locale, then calendar data rules for that locale should be used. The exception is iso8601 format. If someone is using that format, then locale should not override calendar data rules. closes elastic#58479 # Conflicts: # modules/ingest-common/src/main/java/org/elasticsearch/ingest/common/DateFormat.java # modules/ingest-common/src/test/resources/rest-api-spec/test/ingest/30_date_processor.yml # server/src/main/java/org/elasticsearch/common/time/DateFormatters.java # server/src/main/java/org/elasticsearch/common/time/IsoCalendarDataProvider.java # server/src/main/java/org/elasticsearch/index/mapper/DateFieldMapper.java # server/src/main/java/org/elasticsearch/script/JodaCompatibleZonedDateTime.java
pgomulka
added a commit
that referenced
this pull request
Jul 1, 2020
Date processor was incorrectly parsing week based dates because when a weekbased year was provided ingest module was thinking year was not on a date and was trying to applying the logic for dd/MM type of dates. Date Processor is also allowing users to specify locale parameter. It should be taken into account when parsing dates - currently only used for formatting. If someone specifies 'en-us' locale, then calendar data rules for that locale should be used. The exception is iso8601 format. If someone is using that format, then locale should not override calendar data rules. closes #58479
pgomulka
added a commit
that referenced
this pull request
Jul 1, 2020
Date processor was incorrectly parsing week based dates because when a weekbased year was provided ingest module was thinking year was not on a date and was trying to applying the logic for dd/MM type of dates. Date Processor is also allowing users to specify locale parameter. It should be taken into account when parsing dates - currently only used for formatting. If someone specifies 'en-us' locale, then calendar data rules for that locale should be used. The exception is iso8601 format. If someone is using that format, then locale should not override calendar data rules. closes #58479
pgomulka
added a commit
that referenced
this pull request
Jul 2, 2020
…58805) Date processor was incorrectly parsing week based dates because when a weekbased year was provided ingest module was thinking year field was not present on a date and was trying to applying the logic for dd/MM type of dates. Date Processor is also allowing users to specify locale parameter. It should be taken into account when parsing dates - currently only used for formatting. If someone specifies 'en-us' locale, then calendar data rules for that locale should be used. The iso8601 ingest format is still using joda implementation closes #58479
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Date processor was incorrectly parsing week based dates as when a
weekbased year was provided ingest module was thinking year was not
on a date and was trying to applying the logic for
dd/MMtype ofdates.
For testing ingest has to have access to ISOCalendarDataProvider in
order to correctly calculate week based dates with ISO rules.
Date Processor is also allowing users to specify locale parameter. It
should be taken into account when parsing dates - currently only used
for formatting. If someone specifies 'en-us' locale, then calendar data
rules for that locale should be used.
The exception is iso8601 format. If someone is using that format,
then locale should not override calendar data rules.
closes #58479