SQL: Fix parsing of dates with milliseconds (#30419)

Dates internally contain milliseconds (which appear when converting them
to Strings) however parsing does not accept them (and is being strict).
The parser has been changed so that Date is mandatory but the time
(including its fractions such as millis) are optional.

Fix #30002
This commit is contained in:
Costin Leau 2018-05-10 20:14:54 +03:00 committed by GitHub
parent 519768b5d3
commit 52580b5ca8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 15 additions and 2 deletions

View File

@ -115,6 +115,9 @@ Rollup::
* Validate timezone in range queries to ensure they match the selected job when
searching ({pull}30338[#30338])
SQL::
* Fix parsing of Dates containing milliseconds ({pull}30419[#30419])
[float]
=== Regressions
Fail snapshot operations early when creating or deleting a snapshot on a repository that has been
@ -201,6 +204,8 @@ Rollup::
* Validate timezone in range queries to ensure they match the selected job when
searching ({pull}30338[#30338])
SQL::
* Fix parsing of Dates containing milliseconds ({pull}30419[#30419])
Allocation::
@ -241,6 +246,9 @@ Reduce the number of object allocations made by {security} when resolving the in
Respect accept header on requests with no handler ({pull}30383[#30383])
SQL::
* Fix parsing of Dates containing milliseconds ({pull}30419[#30419])
//[float]
//=== Regressions

View File

@ -31,7 +31,7 @@ import static org.elasticsearch.xpack.sql.type.DataType.NULL;
*/
public abstract class DataTypeConversion {
private static final DateTimeFormatter UTC_DATE_FORMATTER = ISODateTimeFormat.dateTimeNoMillis().withZoneUTC();
private static final DateTimeFormatter UTC_DATE_FORMATTER = ISODateTimeFormat.dateOptionalTimeParser().withZoneUTC();
/**
* Returns the type compatible with both left and right types

View File

@ -82,10 +82,15 @@ public class DataTypeConversionTests extends ESTestCase {
Conversion conversion = DataTypeConversion.conversionFor(DataType.KEYWORD, to);
assertNull(conversion.convert(null));
// TODO we'd like to be able to optionally parse millis here I think....
assertEquals(new DateTime(1000L, DateTimeZone.UTC), conversion.convert("1970-01-01T00:00:01Z"));
assertEquals(new DateTime(1483228800000L, DateTimeZone.UTC), conversion.convert("2017-01-01T00:00:00Z"));
assertEquals(new DateTime(18000000L, DateTimeZone.UTC), conversion.convert("1970-01-01T00:00:00-05:00"));
// double check back and forth conversion
DateTime dt = DateTime.now(DateTimeZone.UTC);
Conversion forward = DataTypeConversion.conversionFor(DataType.DATE, DataType.KEYWORD);
Conversion back = DataTypeConversion.conversionFor(DataType.KEYWORD, DataType.DATE);
assertEquals(dt, back.convert(forward.convert(dt)));
Exception e = expectThrows(SqlIllegalArgumentException.class, () -> conversion.convert("0xff"));
assertEquals("cannot cast [0xff] to [Date]:Invalid format: \"0xff\" is malformed at \"xff\"", e.getMessage());
}