Documentation preview:

• ✨ Changed pages

Pinging @elastic/es-ql (Team:QL)

Pinging @elastic/elasticsearch-esql (:Query Languages/ES|QL)

I think we'll have to separate DATE_TIME and DATE even though we'll use the same representation for them.
We've done this in SQL and I don't see a reason why we won't end up with the same approach in ESQL.
While DATE might be an ESQL-only type, it's quite handy from a query prespective.

That said, I'm fine with this PR however it's worth raising this up with the group along side a list of functions that work only on DATE vs DATE_TIME (as we do in SQL).

Taking a look at our SQL time functions, I think we can group them in some five categories:

• conversion (parsing, formatting)
• updating (adding, truncating, diffing)
• snapshotting (now(), today() etc.)
• extraction (like day_of_week(), week_of_year() etc.)
• histogram.

The functions that take a DATE also take a DATETIME (the use of TIME is less prevalent).

Having DATE (and possibly TIME) would be a nice convenience, but doesn't seem like it'd unlock functionality not possible without it, just looking at the above.

(Fwiw, other significant pipe languages don't expose similar types.)

In any case, with existing date_extract()/_format()/_parse()/_trunc(), we would need to align one one side or the other, IMO.

Sync'd about it and decided to keep things as are: we might add a DATE synthetic type and have the date_xxx() functions accept both DATETIME and DATE.