Elasticsearch: Support default time zone in elastic cluster rather than always base epoch conversion on UTC

[roytmana]

I am not an expert with date/time but I was wondering if this would make sense to you. It would certainly be very helpful for me :-)

Describe the feature:
Allow configuring a ES cluster with specific time zone so that it is used instead of UTC when converting JSON time to epoch and when converting it back to string representation. This will allow applications targeted to a single time zone to work without having to always use complete date/time representation or convert dates (without time zone) to UTC before sending to ES for ingestion orqueries

Rationale
When many "consumers" that are mostly use local time communicate with ES it is not easy to ensure that all of them convert local date/time to UTC or use full date/time with timezone when issuing their queries so it is quite possible that some will send local dates without time zones and get incorrect results. Also for applications that use large number of dates (time is not desired) having to send them in full date/time/zone form could noticeable increase _source size.
I am not sure if using long date format with time (always 00:00:00 for this cases) would have any effect on bucketing

https://discuss.elastic.co/t/storing-dates-in-elastic-best-practices/57496

[jpountz]

I think making a default time zone configurable would be extremely trappy. Daylight saving times can make parsing ambiguous when the time goes back since it is not obvious whether we are before or after the change, they make date_histogram buckets have variable lengths, etc. And there are probably many other problems I have not thought about yet: time zones are hard.

[makeyang]

@roytmana @jpountz
how about make timz_zone a immutable static meta data per index?

[jpountz]

How would it help?

[makeyang]

since it is immutable, "parsing ambiguous when the time goes back" won't happen. one index will use one timezone forever.

[jpountz]

That would only work with a fixed time-zone (eg. UTC+1), while I believe users who want this feature would like to specify a dynamic one like Europe/Paris, which creates ambiguity because of daylight saving times.

Dates and time zones are hard, let's not make room for bugs.