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 date parsing to be compatible with joda #36155

Merged
merged 3 commits into from
Dec 3, 2018

Conversation

pgomulka
Copy link
Contributor

@pgomulka pgomulka commented Dec 3, 2018

ZonedDateTime toString format yyyy-MM-ddTHH:mmZ is failing parsing by
our java-time DateFormatters whereas it passes Joda parsing. The pattern
is strict_date_optional_time||epoch_millis

ZonedDateTime toString format yyyy-MM-ddTHH:mmZ is failing parsing by
our java-time DateFormatters whereas it passes Joda parsing. The pattern
is strict_date_optional_time||epoch_millis
@pgomulka pgomulka requested a review from spinscale December 3, 2018 12:32
@pgomulka pgomulka self-assigned this Dec 3, 2018
@@ -85,13 +85,13 @@
.optionalStart()
.appendFraction(MILLI_OF_SECOND, 3, 3, true)
.optionalEnd()
.optionalEnd()
Copy link
Contributor Author

Choose a reason for hiding this comment

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

this is just moving the zoneId below the optional section of seconds/milliseconds. Hard to see with this formatting

//failing below
assertSameDate("2015-01-04T00:00Z", "strict_date_optional_time||epoch_millis");
}
//Failing
Copy link
Contributor Author

Choose a reason for hiding this comment

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

will delete these if the PR is ok, but it helps investigating

Copy link
Contributor

Choose a reason for hiding this comment

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

for sure I'm fine with the PR in general! :-)

@@ -390,6 +391,28 @@ public void testDuelingStrictParsing() {

assertSameDate("2012-W31-5", "strict_weekyear_week_day");
assertParseException("2012-W1-1", "strict_weekyear_week_day");
//failing below
assertSameDate("2015-01-04T00:00Z", "strict_date_optional_time||epoch_millis");
Copy link
Contributor

Choose a reason for hiding this comment

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

can you just use strict_date_optional_time and remove epoch_millis? Also, can yo move this to the other strict_date_optional_time checks?

Can you also move this strict_date_optional_time checks to the others in this method?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

absolutely - will clean this up

TemporalAccessor parse = formatter.parse("2015-01-04T00:00Z");
}
//Passing
public void testParsingJoda(){
Copy link
Contributor

Choose a reason for hiding this comment

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

these two methods are not needed anymore, correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

these are not needed. I only left them if you wanted to verify that quickly on your own

Copy link
Contributor

@spinscale spinscale left a comment

Choose a reason for hiding this comment

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

LGTM once CI is happy due to checkstyle. Thanks for finding this!

@@ -33,6 +33,7 @@
import java.util.Locale;

import static org.hamcrest.Matchers.containsString;
import static org.hamcrest.Matchers.equalTo;
Copy link
Contributor

Choose a reason for hiding this comment

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

unused import

@colings86 colings86 added the :Core/Infra/Core Core issues without another label label Dec 3, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

@colings86
Copy link
Contributor

Please remember to add all relevant labels (area label, version label(s) and change type label) on all PRs and please look for this as part of reviews. The release note generation process is made much harder when PRs are not labelled correctly.

@pgomulka
Copy link
Contributor Author

pgomulka commented Dec 3, 2018

sorry about that @colings86 . totally slipped my mind. Thanks for fixing this

@pgomulka pgomulka merged commit f486f63 into elastic:java-time Dec 3, 2018
@colings86
Copy link
Contributor

@pgomulka note that I didn't add the change type and version labels so could you please add those?

@spinscale
Copy link
Contributor

@colings86 I do not think that this is necessary, as this PR is merged into a feature branch?

@colings86
Copy link
Contributor

Sorry I didn't see that this was for a feature branch. Area label only is fine then :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Core/Infra/Core Core issues without another label
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants