How to display specific timezone in table results instead of user preference timezone?

[michael_sleep]

I spent a fair amount of time perusing Google and Splunk Answers but couldn't seem to find a solution that made sense... essentially the requirement I have is to display a timestamp in a Splunk dashboard in a specific timezone, regardless of what user preferences people have configured. The reason for this requirement is that we have several members located globally that have a legitimate/more frequent need to have their own timezone (so we can't ask them to change to Eastern) but the dashboard in question specifically needs to report on issues using Eastern time (they need to look the same for everyone). I feel like there must be some simple way to do this that I just haven't found.

I'm not doing anything complicated right now, I'm just converting a UNIX timestamp with strftime:

| eval openTime=strftime(openTime,"%m/%d/%Y %H:%M:%S")
| eval closedTime=strftime(closedTime,"%m/%d/%Y %H:%M:%S")

When I display them in a table they display in whatever the user preference is for timezone. Every solution I've tried doesn't really seem to be a solution. It is easy to convert a timestamp with a timezone to unix. It is also easy to convert unix to a timestamp that shows your local timezone... but so far it seems impossible to convert a unix timestamp to a specific timezone (and have it display in that timezone instead of whatever the user has configured).

Thoughts? To re-iterate, we cannot ask these users to change their timezone preference but these times MUST be shown in Eastern.

[Turtlezorg]

Try this:

```Gets the original timestamp. In this case it's when the latest data was ingested into Splunk. The friendly time will be in YOUR LOCAL time zone set in Splunk preferences.```
index=something sourcetype=something
| stats latest(_time) as LATEST_DATA_PULL_TIME
| eval LATEST_DATA_PULL_TIME_friendly_local=strftime(LATEST_DATA_PULL_TIME, "%m/%d/%Y %I:%M:%S %P")

```Sets the TARGET time zone.```
| eval to_tz="US/Eastern"

```Converts timestamp to friendly showing YOUR LOCAL time zone, then replaces YOUR LOCAL time zone with the TARGET time zone, then converts the time back into epoch. This creates a new epoch timestamp which is shifted by the difference between YOUR LOCAL time zone and the TARGET time zone.```
| eval LATEST_DATA_PULL_TIME_tz_replaced=strptime(mvindex(split(strftime(LATEST_DATA_PULL_TIME, "%c|%Z"), "|"), 0)+"|"+to_tz, "%c|%Z")

```Calculates the difference between the original timestamp and the shifted timestamp, essentially returning the difference between YOUR LOCAL time zone and the TARGET time zone, in seconds.```
| eval time_diff=LATEST_DATA_PULL_TIME-LATEST_DATA_PULL_TIME_tz_replaced

```Increses the original timestamp by the difference calculated in the previous step, and then converts it to friendly time.```
| eval LATEST_DATA_PULL_TIME_tz_corrected_friendly=strftime(LATEST_DATA_PULL_TIME+time_diff, "%m/%d/%Y %I:%M:%S %P")

[PickleRick]

Short answer - you can't. The timestamps are displayed in your user's local timezone and there is no (at least publicly known) way to change it.

And it makes some sense because it greatly reduces the probability of many issues arising from "hidden" timezone and time being "improperly" displayed.

Having said that, the long answer is you "can" do this but it's ugly as hell. There are some situations (like working in a multinational environment where you sometimes have to "juggle" between different timezones). The ugly way to show such timestamp is to offset the actual timestamp by the difference between zones and render "your local" timestamp and pretend it's from another timezone something like (pseudocode) - in case of CET vs PDT (check which way the offset should be, because I'm not sure)

strftime(_time+(CET-PDT),"%format_without_tz")."PDT"

You could define a macro for that.

[yuanliu]

An even longer answer: How can search head know who is viewing and which time zone each user prefers - if not from user preference?

By the end of day, this is not a technical question, but a design question.  As you stated, you have a global workforce, implying that you cannot force everyone to accept Eastern US time.  Is this correct?  If it is, you need to ask yourself:

1. What is the reason why you cannot allow those special users to set their preference?
2. If there is a good reason for 1, the second question is: Will a dashboard selector be acceptable?

One way or another, you need to give your global workforce a method to tell search head their preference.  After the user makes a selection, then yes, there is a way to display specific time zone.

[PickleRick]

I can think of at least one valid use case for using multiple timezones - if your team works globally and wants to know what local time at the originating site is (for example to decide whether something happened during workhours or not). Yes, it could be done differently but showing local times is the most natural thing.

But I admit that it's a relatively rare use case and allowing users to easily display dates in various timezones (especially without explicit timezone information in the rendered timestamp) can lead to a huge load of confusion and badly created dashboards.