I set the "Timezone for date formatting" to UTC in the Advanced settings, so all my dashboards and visualizations use it as expected. However the SIEM app seems to use the browser settings which throws things off. Is there a way to force the SIEM app to use UTC time?
Hi there Wes,
I've verified that setting the "Timezone for date formatting" (dateFormat:tz) setting in Kibana Advanced settings is correctly formatting dates throughout the SIEM App in version 7.5 and the soon to be released 7.6, but perhaps this was present in a previous release and has since been fixed.
Would you be willing to provide additional information about your deployment (version, browser, etc) and where in the app you're seeing incorrectly formatted dates?
Thanks!
Garrett
Hey Garrett, I'm running 7.5.2 and I've got dateFormat:tz set to UTC.
In one such document, I've got a dashboard that shows the correct time in UTC. However in the SIEM app, it shows the following:
Notice how it's adding 8 hours. I'm based in Seattle WA, which is +8 to UTC.
Thanks for the added details Wes!
So looks like it's just the tooltip that's the culprit. The dates shown throughout the app are being formatted in UTC as per your Kibana Advanced Settings, but the first two dates within tooltip are being formatted as per your browser's timezone. I opened this issue to track when attempting to recreate, but didn't make the connection since the other dates were being formatted correctly.
Sorry for the confusion -- we'll get this taken care of. 
It's more than just the tooltip - the 'Events' tab on the Host page displays the browser time:
Also the "Last event" under the Hosts tab says "In 6 hours". Thanks again for the help!
Hey there Wes -- I think I've gotten to the bottom of it 
I just cross-referenced the Events table on the Hosts page with the same query from the dev console and it is indeed respecting the configured dateFormat:tz value. What might be throwing us off here is that the datetimes throughout the app also conform to the dateFormat setting, which defaults to MMM D, YYYY @ HH:mm:ss.SSS and thus shows no timezone, which can give the impression they're in browser local time. Adding a Z to the dateFormat setting will ensure dates are rendered with the configured tz offset.
Here are some images for details:
dateFormat:tz UTC
dateFormat:tz US/Pacific
dateFormat:tz US/Pacific
dateFormat MMM D, YYYY @ HH:mm:ss.SSS Z
As for the "Last event" under the Hosts tab reading in 6 hours... I verified in the source that this is using the dateFormat:tz configured, but it is showing it relative to your browsers timezone (hence being in the future), similar to the first date within the tooltip above.
I spoke with a team member today about this and the intent here is to provide some bearing for when an event happened relative to the user's current time. I'm going to add some notes to the issue I opened above to see what we can do to better communicate this to the user.
Let me know if you have any other questions, and I hope this clears things up -- thanks for posting!
Cheers!
Garrett
Thanks for the continued help. Unfortunately it looks like I've still got a discrepancy. I've got dateFormat:tz set to UTC and the documents in the SIEM app are still showing +8 hours.
Config:
SIEM app:
Custom dashboards of same log data:
Notice how my dashboards have UTC and my SIEM app is 8 hours off. Again, they're the same 6 logs.
Hey again Wes, apologies for the delay in response.
Looks like the SIEM Event datetimes are +8hr from the ones on your custom dashboard. If the datetimes on your custom dashboard are indeed UTC (and SIEM is showing PST), I'd expect the the SIEM Events to be -8hr since PST is UTC-08:00. Perhaps your custom dashboard is formatting the datetimes to PST?
To verify for sure, can you cross-references the dates from your custom dashboard with the response from using the inspect feature on the dashboard?
Heya Wes, are you sure that's the request for the v1 Corelight HTTP Search table you were referencing above and not another visualization? The time_zone parameter in the request posted is going to be specific to the date_histogram aggregation, and the data on your table didn't appear to be bucketed in 10m intervals.
If you could verify one of the timestamps from your v1 Corelight HTTP Search table with the exact value being returned from Elasticsearch (along with any time-formatting parameters within scope) then I think we can narrow this down.
Yeah that request was from a different viz. The top entry shows this at the moment:
And looking at the response via the inspect tool, the raw value for @timestamp is:
So I think it's safe to say that my dashboards are displaying time in UTC. Going a bit further, here's what the equivalent looks like in the SIEM app. A little difficult to see the record in the background, but notice how the raw value in the response is 2020-02-11 23:59:55 yet the events table (background) shows Feb 12, 2020 @ 07:59:55.000:
Thanks again for the continued help!
That's the ticket -- thanks for hanging in @wconnell!
So looks like your @timestamp field mapping format does not include any timezone designators. And as mentioned in that section of the wiki:
If no UTC relation information is given with a time representation, the time is assumed to be in local time.
which is what is resulting in your SIEM datetimes being off. We get the date back from ES (as ingested), it gets instantiated as browser local time, then formatted to whatever format is configured in your Kibana Advanced Settings. Since you have UTC configured, it's going from PST -> UTC which is why your SIEM datetimes are displaying as UTC +8hr.
That said, this is definitely something we'll want to fix and I've opened this issue to track it. As a workaround, you could update your field mapping/beats config/ingest pipeline to ensure @timestamp is being ingested as ISO 8601 with timezone designators (e.g. 2020-02-11T23:59:55Z) and that should do the trick.
Thanks again for reporting this @wconnell, and please do let us know if you come across anything else or have any questions -- happy to help! 
Cheers!
Garrett
Great catch. Thanks so much for the help! I'll see what I can do to add timezone designators to the logs I'm pushing to Elastic. Thanks again.
1 Like
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.