honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix decimal point parsing for date_optional_time backport(#43859) #44050 

Joda allowed for date_optional_time and strict_date_optional_time a decimal point to be . dot or , comma
For our java.time implementation we should also extend this for strict_date_optional_time-nanos
the approach to fix this is the same as in iso8601 parser
closes #43730
This commit is contained in:
Przemyslaw Gomulka 2019-07-08 09:56:01 +02:00 committed by GitHub
parent 2176d09c37
commit 247f2dabad
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 32 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
server/src/main/java/org/elasticsearch/common/time/DateFormatters.java
View File

@ -112,6 +112,10 @@ public class DateFormatters {
.optionalStart()
.appendFraction(NANO_OF_SECOND, 1, 9, true)
.optionalEnd()
.optionalStart()
.appendLiteral(',')
.appendFraction(NANO_OF_SECOND, 1, 9, false)
.optionalEnd()
.optionalEnd()
.optionalStart()
.appendZoneOrOffsetId()
@ -139,6 +143,10 @@ public class DateFormatters {
.appendFraction(NANO_OF_SECOND, 3, 9, true)
.optionalEnd()
.optionalStart()
.appendLiteral(',')
.appendFraction(NANO_OF_SECOND, 3, 9, false)
.optionalEnd()
.optionalStart()
.appendZoneOrOffsetId()
.optionalEnd()
.optionalStart()
@ -940,6 +948,10 @@ public class DateFormatters {
.optionalStart()
.appendFraction(NANO_OF_SECOND, 1, 9, true)
.optionalEnd()
.optionalStart()
.appendLiteral(',')
.appendFraction(NANO_OF_SECOND, 1, 9, false)
.optionalEnd()
.optionalStart().appendZoneOrOffsetId().optionalEnd()
.optionalStart().appendOffset("+HHmm", "Z").optionalEnd()
.optionalEnd()

20
server/src/test/java/org/elasticsearch/common/joda/JavaJodaTimeDuellingTests.java
View File

@ -40,6 +40,26 @@ import static org.hamcrest.Matchers.is;
public class JavaJodaTimeDuellingTests extends ESTestCase {
//these parsers should allow both ',' and '.' as a decimal point
public void testDecimalPointParsing(){
assertSameDate("2001-01-01T00:00:00.123Z", "strict_date_optional_time");
assertSameDate("2001-01-01T00:00:00,123Z", "strict_date_optional_time");
assertSameDate("2001-01-01T00:00:00.123Z", "date_optional_time");
assertSameDate("2001-01-01T00:00:00,123Z", "date_optional_time");
// only java.time has nanos parsing, but the results for 3digits should be the same
DateFormatter jodaFormatter = Joda.forPattern("strict_date_optional_time");
DateFormatter javaFormatter = DateFormatter.forPattern("strict_date_optional_time_nanos");
assertSameDate("2001-01-01T00:00:00.123Z", "strict_date_optional_time_nanos", jodaFormatter, javaFormatter);
assertSameDate("2001-01-01T00:00:00,123Z", "strict_date_optional_time_nanos", jodaFormatter, javaFormatter);
assertParseException("2001-01-01T00:00:00.123,456Z", "strict_date_optional_time");
assertParseException("2001-01-01T00:00:00.123,456Z", "date_optional_time");
//This should fail, but java is ok with this because the field has the same value
// assertJavaTimeParseException("2001-01-01T00:00:00.123,123Z", "strict_date_optional_time_nanos");
}
public void testIncompatiblePatterns() {
// in joda 'y' means year, this is changed to 'u' in java.time. difference is in before era yeaers
assertSameMillis("-0001-01-01", "yyyy-MM-dd", "8uuuu-MM-dd");