SQL: Make parsing of date more lenient #52137
Conversation
|
Pinging @elastic/es-search (:Search/SQL) |
Make the parsing of date more lenient
- as an escaped literal: `{d '2020-02-10[[T| ]10:20[:30][.123456789][tz]]'}`
- cast a string to a date: `CAST(2020-02-10[[T| ]10:20[:30][.123456789][tz]]' AS DATE)`
Closes: elastic#49379
|
I'm not sure about the escaped literal enhancement, since MS-SQL docs only mention the |
| // double check back and forth conversion | ||
| assertEquals(date(1581292800000L), conversion.convert("2020-02-10 10:20")); | ||
| assertEquals(date(-125908819200000L), conversion.convert("-2020-02-10 10:20:30.123")); | ||
| assertEquals(date(1581292800000L), conversion.convert("2020-02-10 10:20:30.123456789")); |
There was a problem hiding this comment.
For sake of completeness, I'd suggest a test without the duration separator, but with a timezone (or a Z).
| @@ -42,6 +42,30 @@ | |||
| .appendLiteral('T') | |||
| .append(ISO_LOCAL_TIME) | |||
| .toFormatter().withZone(UTC); | |||
| private static final DateTimeFormatter DATE_ESCAPED_LITERAL_FORMATTER_WHITESPACE = new DateTimeFormatterBuilder() | |||
There was a problem hiding this comment.
I think the name of the formatters could be more descriptive? The fact that time can be added, but it's optional, imo should be reflected in the formatter's name. Also, not to abuse the length of the names, how about DATE_OPTIONAL_TIME_FORMATTER_WHITESPACE? (ie get rid of ESCAPED_LITERAL keep the FORMATTER and mention the whitespace/'T') Same idea could be applied to the rest of the formatters: `DATE_OPTIONAL_OPTIONAL_TIME_FORMATTER_T, ISO_DATE_OPTIONAL_TIME_FORMATTER_WHITESPACE, ISO_DATE_OPTIONAL_TIME_FORMATTER_T.....
| return LocalDate.parse(dateFormat, ISO_LOCAL_DATE).atStartOfDay(UTC); | ||
| int separatorIdx = dateFormat.indexOf('-'); | ||
| if (separatorIdx == 0) { // negative year | ||
| separatorIdx = dateFormat.indexOf('-', separatorIdx + 1); |
There was a problem hiding this comment.
Since separatorIdx == 0 then the indexOf call should be indexOf('-', 1) right?
| } | ||
| separatorIdx = dateFormat.indexOf('-', separatorIdx + 1) + 3; | ||
| // Avoid index out of bounds - it will lead to DateTimeParseException anyways | ||
| if (separatorIdx >= dateFormat.length() || dateFormat.charAt(separatorIdx) == 'T') { |
There was a problem hiding this comment.
In which situation is the > valid here? (I refer to separatorIdx >= dateFormat.length()) Isn't == enough to detect a date-only string?
There was a problem hiding this comment.
2 lines above we do +3 to move directly after the day part in the string.
If the string passed is something like: 2020-12- then we have moved passed the string's length and dateFormat.charAt() will throw OutOfBounds exception.
I forgot to add a test for that, will do.
Make the parsing of date more lenient
{d '2020-02-10[[T| ]10:20[:30][.123456789][tz]]'}CAST(2020-02-10[[T| ]10:20[:30][.123456789][tz]]' AS DATE)Closes: #49379