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:
parent
519768b5d3
commit
52580b5ca8
|
@ -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
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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());
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue