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

Fix java time formatters that round up #37604

Merged
merged 11 commits into from
Jan 22, 2019

Conversation

spinscale
Copy link
Contributor

@spinscale spinscale commented Jan 18, 2019

In order to be able to parse epoch seconds and epoch milli seconds own
java time fields had been introduced. These fields are however not
compatible with the way that java time allows one to configure default
fields (when a part of a timestamp cannot be read then a default value
is added), which is used for the formatters that are rounding up to the
next value.

This commit allows java date formatters to configure its round up parsing by setting any default values via a consumer. By default all formats are setting JavaDateFormatter.ROUND_UP_BASE_FIELDS for default parsing. The epoch parsers both set different fields and merged date formatters do not set any fields, because this has already been done in the concrete date formatters.

Also the formatter now properly copies the locale and the timezone, fractional parsing has been set to nano seconds with proper width.

Reviewers note: I plan to backport this in 7.0 and 6.7.

In order to be able to parse epoch seconds and epoch milli seconds own
java time fields had been introduced. These fields are however not
compatible with the way that java time allows one to configure default
fields (when a part of a timestamp cannot be read then a default value
is added), which is used for the formatters that are rounding up to the
next value.

This gets even more problematic when the epoch formats are mixed with
other formats like `strict_date_optional_time||epoch_second`, as this
ends up in exceptions being thrown on parsing.

This commit catches this corner case by implementing a special parse
method for those rounding up formatters, that catches the exception and
is calling `parseUnresolved` on the formatter, so that we can manually
intervene and try to create a proper epoch based dates when the other
parsing has failed.

Also the formatter now properly copies the locale and the timezone.
@spinscale spinscale added >non-issue :Core/Infra/Core Core issues without another label labels Jan 18, 2019
@spinscale spinscale requested a review from rjernst January 18, 2019 10:26
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

parsers. This also ensures all pre defined date formatters use nano
seconds, even though the resolution might be smaller.

The epoch formatters need different default parsers, which are
configured in the ctor.

Note: This is not yet the final result in terms of code.
Copy link
Member

@danielmitterdorfer danielmitterdorfer left a comment

Choose a reason for hiding this comment

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

LGTM. I left one minor comment.

@@ -133,9 +133,11 @@ static DateFormatter forPattern(String input) {
return Joda.forPattern(input);
}

input = input.substring(1);
Copy link
Member

Choose a reason for hiding this comment

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

This is to remove the leading "8" from the input pattern but I always find this confusing without a comment.

@spinscale
Copy link
Contributor Author

@elasticmachine run gradle build tests 2

@spinscale spinscale merged commit 4fb68ea into elastic:master Jan 22, 2019
spinscale added a commit to spinscale/elasticsearch that referenced this pull request Jan 22, 2019
In order to be able to parse epoch seconds and epoch milli seconds own
java time fields had been introduced. These fields are however not
compatible with the way that java time allows one to configure default
fields (when a part of a timestamp cannot be read then a default value
is added), which is used for the formatters that are rounding up to the
next value.

This commit allows java date formatters to configure its round up parsing 
by setting default values via a consumer. By default all formats are setting 
JavaDateFormatter.ROUND_UP_BASE_FIELDS for rounding up. The epoch
however parsers both need to set different fields. The merged date
formatters do not set any fields, they just append all the round up formatters.

Also the formatter now properly copies the locale and the timezone, 
fractional parsing has been set to nano seconds with proper width.
jasontedor added a commit to jasontedor/elasticsearch that referenced this pull request Jan 22, 2019
* elastic/master: (43 commits)
  Remove remaining occurances of "include_type_name=true" in docs (elastic#37646)
  SQL: Return Intervals in SQL format for CLI (elastic#37602)
  Publish to masters first (elastic#37673)
  Un-assign persistent tasks as nodes exit the cluster (elastic#37656)
  Fail start of non-data node if node has data (elastic#37347)
  Use cancel instead of timeout for aborting publications (elastic#37670)
  Follow stats api should return a 404 when requesting stats for a non existing index (elastic#37220)
  Remove deprecated FieldNamesFieldMapper.Builder#index (elastic#37305)
  Document that date math is locale independent
  Bootstrap a Zen2 cluster once quorum is discovered (elastic#37463)
  Upgrade to lucene-8.0.0-snapshot-83f9835. (elastic#37668)
  Mute failing test
  Fix java time formatters that round up (elastic#37604)
  Removes awaits fix as the fix is in. (elastic#37676)
  Mute failing test
  Ensure that max seq # is equal to the global checkpoint when creating ReadOnlyEngines (elastic#37426)
  Mute failing discovery disruption tests
  Add note about how the body is referenced (elastic#33935)
  Define constants for REST requests endpoints in tests (elastic#37610)
  Make prepare engine step of recovery source non-blocking (elastic#37573)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants