Managing reports for multiple timezones

[sc0tt]

We currently have 4 servers that send data to the Splunk indexer. Each server is located in US/Eastern, however each server is used by a different geographical region and all log timestamps are US/Eastern. Using the user timezone setting, Splunk will adjust the time to the user's local timezone. However, for reporting purposes I do not want the times to be displayed in local time, but rather with respect to each reporting region. Currently, I am using the below eval in my reports:

| eval _time=case(host="Server-1", _time + (60 * 60), host="Server-2", _time + (210 * 60),host="Server-3", _time + (300 * 60), 1=1, _time)`

This works, but is there a better way to do this so reports do not need to be modified during timezone changes and when new geographical regions come online?

[linu1988 · Accepted solution]

Hello,
Your approach is quite correct, not much you can do about this while doing a report if your search head is in different region.

[sc0tt]

Thanks for the feedback. I ended up creating a timezone search macro to handle this so that I only have to change it one place. I think this is best I can do. I wish Splunk had a feature that could display reports for specified time zones.

[sc0tt]

Thanks and sorry for not responding sooner. The issue is that I don't always want the time to to be displayed in the local timezone of a Splunk user. Often, I want reports to be adjusted for specific geographical regions depending on the server and displayed on a dashboard--kind of like a newsroom with world clocks. Reports are then emailed to outside parties in these regions so they need to be displayed for the correct time zone.

[kristian_kolb]

Perhaps I'm not understanding the full picture here, but;
a) all timestamps from within the events are converted to epoch internally, i.e. from that point on, there are no timestamps that need to be changed for the actual data.
b) for presentation purposes the timestamp can be displayed in the local timezone of the user.
c) having log sources and indexers in different timezones makes correct definition of TZ settings important (either if the timestamp in the event contains this info, or if not, that it is being explicitly set in the config file).

/k