Getting Data In

How to view same results with different timezone users

New Member



All my data sources and Indexers and Search heads are in PST time zone and Indexer time zones are PST. I have users in different timezones EST,CST,PST . My question is when a EST user searches in search head for (3.00pm to 4.00pm timerange) and CST user searches in search head for (3.00pm to 4.00pm timerange) will the results same or different for both the users?
I dont want to know how to change user timezone in settings and also in props.conf. I want how to view the same results even though the users are in different timezones.

0 Karma

Esteemed Legend

The answer is: it depends on each user's personal settings. Go to <Your Login Name> -> Account settings -> Time zone and set it to what you desire. From that point on, the Timepicker will normalize to that Time zone. If you set it to US/Central then pick Yesterday, you will get a different set of values than a user who has a setting of US/Pacific, just as you would expect/desire.

0 Karma

Super Champion

So with everything being indexed in PST, a user in CST would have data 2 hours shifted from a user in PST, even though the data itself is all the same, the time picker goes off of the user preferences.

you can either make sure everyone is listed as PST users (which you've mentioned you don't want to do)
or you can add this to syntaxes (given that your data has an offset field that says what timezone it is in, like -5:00):

|base search earliest=just a little before the earliest targeted date latest=just a little ahead of the latest targeted date
| addinfo 
| convert mktime(dateTime) as epochDateTime timeformat="%Y-%m-%d %H:%M:%S.%6N %:z" 
| eval shifted_time=epochDateTime-(abs(date_zone)*60) 
| eval shiftedMaxTime=info_max_time-(abs(date_zone)*60) 
| eval shiftedMinTime=info_min_time-(abs(date_zone)*60) 
| eval earliest=relative_time(shiftedMinTime, "+1w@w1")|convert ctime(earliest) as earliest timeformat="%Y-%m-%d %H:%M:%S.%6N %:z" 
| eval latest=relative_time(shiftedMaxTime, "@w1")|convert ctime(latest) as latest timeformat="%Y-%m-%d %H:%M:%S.%6N %:z" 
| eval offset=case(like(earliest,"%12:00") OR like(latest,"%12:00"),43200, like(earliest,"%11:00") OR like(latest,"%11:00"),39600, like(earliest,"%10:00") OR like(latest,"%-10:00"),36000, like(earliest,"%09:00") OR like(latest,"%09:00"),32400, like(earliest,"%08:00") OR like(latest,"%08:00"),28800, like(earliest,"%07:00") OR like(latest,"%07:00"),25200, like(earliest,"%06:00") OR like(latest,"%06:00"),21600, like(earliest,"%05:00") OR like(latest,"%05:00"),18000, like(earliest,"%04:00") OR like(latest,"%04:00"),14400, like(earliest,"%03:00") OR like(latest,"%03:00"),10800, like(earliest,"%02:00") OR like(latest,"%02:00"),7200, like(earliest,"%01:00") OR like(latest,"%01:00"),3600, like(earliest,"%00:00") OR like(latest,"%00:00"),0)
|eval earliest=strptime(earliest,"%Y-%m-%d %H:%M:%S.%6N %:z")-offset
|eval latest=strptime(latest,"%Y-%m-%d %H:%M:%S.%6N %:z")-offset
| where shifted_time>=earliest AND shifted_time<=latest 
| eval _time=shifted_time+offset

this could be trimmed down or edited to fit exactly what you need. We have a similar situation where all data is indexed CST but data comes from other timezones and users login from other timezones. This specific chunk of syntax works for our set of needs. If you don't need to worry about data coming in from other timezones, just the users, the offset eval could be severely trimmed down to just include PST/PDT

0 Karma
Get Updates on the Splunk Community!

Build Scalable Security While Moving to Cloud - Guide From Clayton Homes

 Clayton Homes faced the increased challenge of strengthening their security posture as they went through ...

Mission Control | Explore the latest release of Splunk Mission Control (2.3)

We’re happy to announce the release of Mission Control 2.3 which includes several new and exciting features ...

Cloud Platform | Migrating your Splunk Cloud deployment to Python 3.7

Python 2.7, the last release of Python 2, reached End of Life back on January 1, 2020. As part of our larger ...