Kibana: Kibana Server time and PC time doesn鈥檛 match

Created on 5 Apr 2017  路  10Comments  路  Source: elastic/kibana

Kibana version: 5.2.0 and 5.3.0

Elasticsearch version: 5.2.0 and 5.3.0

Server OS version: Windows 10

Browser version: 57.0.2987.133

Browser OS version: Windows 10

Original install method: download page

Description of the problem including expected versus actual behavior:
I have a strange problem. Basically, when I run Kibana Server, its server time and my PC's local time doesn't match. The problem has started appearing recently -- _not sure but maybe, just after daylight saving time 2017 in the UK last weekend_.

kibana-server-time

I realised that after seeing my documents stored at wrong timestamp via Kibana. When I search them directly through ES APIs, timestamp looks correct. However, in Kabana, timestamp looks one hour ahead. For example, a document stored at 09:00.00 looks 10:00:00. Therefore, you cannot retrieve data using "last 15 minutes" pre-defined time range.

I have checked Kibana -> Advanced Settings -> dateFormat:tz (Default: Browser)

I replaced the default value (Browser) with "UCT", and this allowed me to see the correct timestamp at Kibana. But, the time range feature (e.g. discover data '_last 15 minutes_' etc.) still doesn't work. So, I always have to define an absolute date-time, or a wider range predefined datetime such as "_today_". Also, I don't understand why I should play with advanced settings. Because everything was pretty much perfect by default values before.

Steps to reproduce:
n/a

Operations bug

All 10 comments

Kibana's server timestamp will use UTC time. Kibana's browser timestamps by default(Browser in advanced settings) will request using your current timezone.

Can you share an example of one of your timestamps in elasticsearch? Checking for what the timezone looks like.

Mapping for timestamp in Kibana:
"@timestamp": {"type": "date", "format": "yyyy-MM-dd HH:mm:ss.SSS"

Example timestamp entry in elasticsearch:
{"@timestamp":"2017-04-03 14:45:42.552"}

This morning, I tested new Kibana v5.4 on different PCs. Unfortunately, the same behaviour continues. As a result, Kibana doesn't work properly to visualise data considering the time filter provided.

Hello, I'm currently using the kibana 5.6 with the exact same issue. Any updates on it?
PS: I'm in Brasil

I did some digging, starting in 5.0 it looks like we started intentionally logging in UTC with https://github.com/elastic/kibana/pull/8534. Can you verify that this is "correct" for you?

If it is I'll close this out so we can merge the discussion with the enhancement request for local tz logs at https://github.com/elastic/kibana/issues/12175

I tested the same scenario using the latest (5.6.3) Elasticsearch and Kibana today. As @jbudz said, Kibana console logs are set in UTC intentionally. However, I don't think this is a good idea for an enterprise application. At least, there should be a configuration in kibana.yml allowing us to change it considering the requirements of our system.

Apart from this, I reckon the second part of my post is more interesting. In default settings, Kibana shows my stored documents in wrong timestamp. For instance, when I store a document with timestamp like "October 17th 2017, 15:34:10.150", I see the same record on Kibana Discover tab as having timestamp "October 17th 2017, 16:34:10.150" even though Elasticsearch has it with the right timestamp.

I am able to fix this by playing with Advanced Settings (dateFormat:tz) and list it on Discover tab as it is supposed to be. But this leads to another problem. Kibana changes its system time and I cannot use Time Range options properly.

I'm seeing this odd behaviour on Kibana 6.2.2.
Elasticsearch has timestamps in UTC, Kibana Discover shows timestamps in UTC, however "Last N" time range is calculated from local timezone of server (i.e. local tz of server is UTC+4, if I try to show docs in "Last 24 hours", the most recent ones would be in 4 hours prior to current time of server).

@chupasaurus I have the same problem. I'm looking for the root of this problem too.

My scenario is using 5.4.1 (ELK)

Looks like this is a bug, i am facing this issue for Kibana 6.2 also.

I can't believe this bug is still ongoing for 6.3.1 Changing tz from kibana does not help.

Was this page helpful?
0 / 5 - 0 ratings