Date time range picker

I am using Kibana 7.3.2 and plan to move to 7.15.1 maybe in the next few months after verifying a few things.

The setup:

The field I'm basing my visual upon is the @timeStamp in UTC
The dashboard's date / time picker is set to the last year
I have the Kibana time zone set to default
Access level of the user is view dashboards only (reporting_user)

I want to create the following bar charts:

  • hour of day
  • day of week
  • date of month
  • week of year
  • month of year

The Problem:

Let's take day of week as an example of my issue:
Say my company HQ is in London, with scripted fields, I can do something like:

def myDate = doc['@timeStamp '].value.withZoneSameInstant(ZoneId.of('Europe/London')); 
myDate.dayOfWeek;
return myDate;

NOTE: Is there another way than using scripted fields to get the value I want?

I can make the day of week bar chart visual using the result return in the above script. (i.e. count of the myDate)

Now, what happens if I'm in New York? How can I display my visuals in the HQ's (London) time zone?

My assumption of the problem: Since I am in the New York time zone (EST) , the date / time picker would select the documents based on EST for the last year. This would mean my data set would be offset by 4 hours?

All the date fields are saved in UTC, which doesn't care about timezones and/or DST. then when you do the query and when you receive results from Elasticsearch, the libraries convert your local time to UTC and get the values based on that.
If you want to force a specific time zone for your displayed data in Kibana, you can do it from the Advanced Settings. The default setting for that is Browser so each person views the data in their specified timezone. You can change that Europe/London for everybody (if you use spaces, for everybody that uses that space)

Ok, I see that the advance setting are specific for each space. That is one solution in getting the right documents selected i.e. past year.

Do you have a suggest how to create the desired bar charts by either:

  1. using the @timeZone natively in some aggregation
  2. converting and parsing the @timeZone to get the right bits while respecting the timezone and/or DST

Thanks for your initial reply!

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.