You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I also got hit by this. Of course it feels like an unnecessary chore to decode what is left after max("2014-09-10T19:04:19.725694", "2014-09-10T11:12:13.432432") -> 1410375855.35215. However, the _source of the compared docs may have many different formats for the time stamp. So what should the result format be for max("2014-09-10T19:04:19.725694", 1410375055.1234, ...)?
If a string format is implemented, IMHO it must be ISO format without time zone and nothing else.
UPDATE/EDIT: Oh, with including milliseconds it means that the value is like UTC-milliseconds since UNIX epoch. Which really is surprising for the user. I first thought it really was a UNIX timestamp.
You can now specify `format` in the request definition for most numeric metric aggregations. The exceptions are Percentile_Ranks, Cardinality and Value_Count as the response type of these can be different from the field type so the formatter won't work.
Closes#6812
If you currently do a max aggregation on a date field, elasticsearch prints the output as a unix timestamp including milliseconds.
Example request:
Example current response:
It would be more preferable if the output would be given in the following format:
Improved response:
The text was updated successfully, but these errors were encountered: