to_datetime.asciidoc 1.3 KB

12345678910111213141516171819202122232425262728293031323334353637
  1. // This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it.
  2. *Examples*
  3. [source.merge.styled,esql]
  4. ----
  5. include::{esql-specs}/date.csv-spec[tag=to_datetime-str]
  6. ----
  7. [%header.monospaced.styled,format=dsv,separator=|]
  8. |===
  9. include::{esql-specs}/date.csv-spec[tag=to_datetime-str-result]
  10. |===
  11. Note that in this example, the last value in the source multi-valued field has not been converted.
  12. The reason being that if the date format is not respected, the conversion will result in a *null* value.
  13. When this happens a _Warning_ header is added to the response.
  14. The header will provide information on the source of the failure:
  15. `"Line 1:112: evaluation of [TO_DATETIME(string)] failed, treating result as null. "Only first 20 failures recorded."`
  16. A following header will contain the failure reason and the offending value:
  17. `"java.lang.IllegalArgumentException: failed to parse date field [1964-06-02 00:00:00]
  18. with format [yyyy-MM-dd'T'HH:mm:ss.SSS'Z']"`
  19. If the input parameter is of a numeric type,
  20. its value will be interpreted as milliseconds since the {wikipedia}/Unix_time[Unix epoch]. For example:
  21. [source.merge.styled,esql]
  22. ----
  23. include::{esql-specs}/date.csv-spec[tag=to_datetime-int]
  24. ----
  25. [%header.monospaced.styled,format=dsv,separator=|]
  26. |===
  27. include::{esql-specs}/date.csv-spec[tag=to_datetime-int-result]
  28. |===