Open
Description
Is your feature request related to a problem? Please describe
Currently as part of #15265 we only support rounding off to nearest epoch granularity based on calendar_interval specified.
This will create issues in search flow if user specifies any different timezone or offset.
Example :
Query parameters :
Calendar interval = Day
TimeZone = America / New york
Date histogram Query Algorithm
2023-07-01 T 04:30:45Z - Original time in UTC
2023-07-01 T 00:30:45 - Converted to EST
2023-07-01 T 00:00:00 - Rounded down to the nearest interval
2023-07-01 T 04:00:00Z - Converted back to UTC
When a key_as_string is generated for the bucket, the key value is stored in America/New_York time, so it’ll display as 2023-07-01 T 00:00:00
Star tree indexing :
2023-07-01 T 04:30:45Z - Original time in UTC
2023-07-01 T 00:00:00Z - Converted during indexing [ Say we have interval as "Day" ]
Date histogram Query algorithm with star tree :
2023-07-01 T 00:00:00Z - Original time in UTC ( rounded off in star tree )
2023-06-30 T 20:00:00 - Converted to EST
2023-06-30 T 00:00:00 - Rounded down to the nearest interval
2023-06-30 T 04:00:00Z - Converted back to UTC
When a key_as_string is generated for the bucket, it incorrectly displays as 2023-06-30 T 00:00:00
Describe the solution you'd like
We need to support timezone and offsets as date dimension parameters as part of star tree mapping. We will then perform rounding based on the same.
Search flow has to ensure that star tree index can be used for date histogram intervals only for supported timezone / offset and fallback to default query otherwise.
Related component
Indexing:Performance
Describe alternatives you've considered
No response
Additional context
No response