# Conflicting logstash timestaps system vs UTC **URL:** \ **Category:** Logstash\ **Created:** [June 7, 2016, 3:00pm UTC](https://discuss.elastic.co/t/conflicting-logstash-timestaps-system-vs-utc/52097 "2016-06-07T15:00:41Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![PepeK](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pepek/32/10185_2.png) [@PepeK](https://discuss.elastic.co/u/PepeK)\ **Post date:** [June 7, 2016, 3:00pm UTC](https://discuss.elastic.co/t/conflicting-logstash-timestaps-system-vs-utc/52097/1 "2016-06-07T15:00:41Z")
Hi, I am posting this from Chile and have patched java with the latest timezone data from [iana.org](http://iana.org): I see conflicting timestamp data in logstash-2.3.2-1(receiving from rsyslog) which is causing kibana to display the logs with one hour behind **logstash index in kibana is using the @timestamp**. ie: > { > "message" =\> "\<14\>Jun 7 10:43:47 kamisama gnome-session: in resource: 0xE30E21", > "@version" =\> "1", > " **@timestamp" =\> "2016-06-07T13:43:47.000Z"** , > "type" =\> "syslog", > "host" =\> "172.16.50.113", > "syslog\_pri" =\> "14", > " **syslog\_timestamp" =\> "Jun 7 10:43:47",** > "syslog\_hostname" =\> "kamisama", > "syslog\_program" =\> "gnome-session", > "syslog\_message" =\> "in resource: 0xE30E21", > " **received\_at" =\> "2016-06-07T14:43:47.650Z",** > "received\_from" =\> "xxx.xxx.xxx.xxx", > "syslog\_severity\_code" =\> 6, > "syslog\_facility\_code" =\> 1, > "syslog\_facility" =\> "user-level", > "syslog\_severity" =\> "informational" > } As you can see _@timestamp_ is different than _received\_at_ and both suppose to be UTC. Local time is 10:43:47 (GMT-4) and UTC Time is 14:43:47 like _received\_at_. Why _"@timestamp" =\> "2016-06-07T13:43:47.000Z"_ is one hour behind? My logstash configuration is just like the example from [Logstash configuration examples | Logstash Reference [8.11] | Elastic](https://www.elastic.co/guide/en/logstash/current/config-examples.html) > filter { > if [type] == "syslog" { > grok { > match =\> ["message", "\<%{NONNEGINT:syslog\_pri}\>%{SYSLOGTIMESTAMP:syslog\_timestamp} %{SYSLOGHOST:syslog\_hostname} %{DATA:syslog\_program}(?:[%{POSINT:syslog\_pid}])?: %{GREEDYDATA:syslog\_message}" ] > add\_field =\> ["received\_at", "%{@timestamp}"] > add\_field =\> ["received\_from", "%{host}"] > } > syslog\_pri { } > date { > match =\> ["syslog\_timestamp", "MMM d HH:mm:ss", "MMM dd HH:mm:ss"] > } > } > } ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [June 9, 2016, 12:05am UTC](https://discuss.elastic.co/t/conflicting-logstash-timestaps-system-vs-utc/52097/2 "2016-06-09T00:05:11Z")
What TZ is set for LS? ---
**Author:** ![PepeK](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pepek/32/10185_2.png) [@PepeK](https://discuss.elastic.co/u/PepeK)\ **Post date:** [June 13, 2016, 2:49pm UTC](https://discuss.elastic.co/t/conflicting-logstash-timestaps-system-vs-utc/52097/3 "2016-06-13T14:49:06Z")
TZ is set to Chile/Continental (CLT) = GMT-4 > **[Time Zone & Clock Changes in Santiago, Chile](https://www.timeanddate.com/time/zone/chile/santiago)** > > Historic, present and future dates for daylight saving time and clock changes. Time changes between years 2022 and 2026 in Chile – Santiago are shown here. > message:\<78\> **Jun 13 10:40:01** hostXX crond[7284]: (root) CMD (/usr/lib/sa/sa1 1 1) @version:1 **@timestamp:June 13th 2016, 09:40:01.000** type:syslog host:172.16.xxx.xxx syslog\_pri:78 syslog\_timestamp:Jun 13 10:40:01 syslog\_hostname:hostXX syslog\_program:crond syslog\_pid:7284 syslog\_message:(root) CMD (/usr/lib/sa/sa1 1 1) **received\_at:June 13th 2016, 10:40:01.735** received\_from:172.16.xxx.xxx syslog\_severity\_code:6 syslog\_facility\_code:9 syslog\_facility:clock syslog\_severity:informational \_id:AVVKNH1jP0nKXsl-abr0 \_type:syslog \_index:logstash-2016.06.13 This is how kibana is displaying... @timestamp is one hour behind.. and I don't know from where is getting that incorrect information. Thanks! ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [June 13, 2016, 10:38pm UTC](https://discuss.elastic.co/t/conflicting-logstash-timestaps-system-vs-utc/52097/4 "2016-06-13T22:38:29Z")
Is that the time that the LS host is using? Could there be a daylight savings thing happening? ---
**Author:** ![PepeK](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pepek/32/10185_2.png) [@PepeK](https://discuss.elastic.co/u/PepeK)\ **Post date:** [June 14, 2016, 3:01pm UTC](https://discuss.elastic.co/t/conflicting-logstash-timestaps-system-vs-utc/52097/5 "2016-06-14T15:01:50Z")
The logstash host has the time properly configured. > # zdump -v -c 2015,2017 Chile/Continental > Chile/Continental -9223372036854775808 = NULL > Chile/Continental -9223372036854689408 = NULL > Chile/Continental Sun May 15 02:59:59 2016 UTC = Sat May 14 23:59:59 2016 CLST isdst=1 gmtoff=-10800 > Chile/Continental Sun May 15 03:00:00 2016 UTC = Sat May 14 23:00:00 2016 CLT isdst=0 gmtoff=-14400 > Chile/Continental Sun Aug 14 03:59:59 2016 UTC = Sat Aug 13 23:59:59 2016 CLT isdst=0 gmtoff=-14400 > Chile/Continental Sun Aug 14 04:00:00 2016 UTC = Sun Aug 14 01:00:00 2016 CLST isdst=1 gmtoff=-10800 > Chile/Continental 9223372036854689407 = NULL > Chile/Continental 9223372036854775807 = NULL > # date > Tue Jun 14 10:52:33 CLT 2016 The java timezone data: > # /usr/java/jdk1.8.0\_92/jre/bin/java -jar /opt/elastic/tzupdater.jar -V > tzupdater version 2.0.3-b01 > JRE tzdata version: **tzdata2016d** > tzupdater tool would update with tzdata version: tzdata2015b I have changed the index to use the _received\_at_ field as a workaround but I would like to understand why the _@timestamp_ is off by 1 hour. Is there something inside the logstash code (a binary perhaps) that is not aware of the current timezones? Should I fill a bug report? ---
**Author:** ![PepeK](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pepek/32/10185_2.png) [@PepeK](https://discuss.elastic.co/u/PepeK)\ **Post date:** [June 20, 2016, 7:30pm UTC](https://discuss.elastic.co/t/conflicting-logstash-timestaps-system-vs-utc/52097/6 "2016-06-20T19:30:29Z")
Got some additional information.. I can say the problem happen when adding the "date" filter to the configuration: > filter { > if [type] == "syslog" { > grok { > match =\> ["message", "\<%{NONNEGINT:syslog\_pri}\>%{SYSLOGTIMESTAMP:syslog\_timestamp} %{SYSLOGHOST:syslog\_hostname} %{DATA:syslog\_program}(?:[%{POSINT:syslog\_pid}])?: %{GREEDYDATA:syslog\_message}" ] > add\_field =\> ["received\_at", "%{@timestamp}"] > add\_field =\> ["received\_from", "%{host}"] > } > syslog\_pri { } > date { > match =\> ["syslog\_timestamp", "MMM d HH:mm:ss", "MMM dd HH:mm:ss"] > } If I comment out the last three lines the problems goes away and @timestamp gets the correct time. { "message" =\> "\<86\>Jun 20 15:25:38 sbfisgdev-lv1 sshd[8484]: pam\_unix(sshd:session): session closed for user root", "@version" =\> "1", **"@timestamp" =\> "2016-06-20T19:25:38.817Z",** "type" =\> "syslog", "host" =\> "xxx.xxx.xxx.xxx", "syslog\_pri" =\> "86", **"syslog\_timestamp" =\> "Jun 20 15:25:38",** "syslog\_hostname" =\> "XXXX-XX1", "syslog\_program" =\> "sshd", "syslog\_pid" =\> "8484", "syslog\_message" =\> "pam\_unix(sshd:session): session closed for user root", **"received\_at" =\> "2016-06-20T19:25:38.817Z",** "received\_from" =\> "xxx.xxx.xxx.xxx", "syslog\_severity\_code" =\> 6, "syslog\_facility\_code" =\> 10, "syslog\_facility" =\> "security/authorization", "syslog\_severity" =\> "informational" } The three time fields are consistent. So, what is the benefit of using the "date" filter? what is going on and why is that behaviour? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 4:51am UTC](https://discuss.elastic.co/t/conflicting-logstash-timestaps-system-vs-utc/52097/7 "2017-07-06T04:51:46Z")