Timezone issue: Is there a search to convert to common utc value?

[subitha_kennedy]

Timezone issue --------different data is visible to different location users, when I select previous month..

condition : | where abc>="-1mon@mon" and abc<"@mon"

Its taking the system time not the common time, so the user is facing issues..

is there any query to convert to common utc value??

[subitha_kennedy]

We are using a query to get results based on previous month and also date range (dd-mm-yy)..

But in our query, we used to get results only for previous month, not for the date range(its not accepting the double quotes ("") for the number, when I remove "". its not accepting the string :(..

query we used for reference...

Isnum is not working with "", if I remove "". string is not working..pls suggest me the solution, tried different ways but nothing is working..

| eval lnum=if(match("1690848000","^[@a-zA-Z]+"),"str","num"), enum=if(match("1688169600","[a-zA-Z]"),"str","num")
| eval latest=case(isnum(1690848000),(1690848000-60),"1690848000"="now",now(),"1690848000"="",now(),lnum!="str","1690848000",1=1,relative_time(now(), "1690848000"))
| eval earliest=case(isnum(1688169600),(1688169600-60),"1688169600"="0","0",enum!="str","1688169600",1=1,relative_time(now(), "1688169600"))

I want to have same data for previous month and also date range filters...This is question..

[yuanliu]

This is still very confusing

---

But in our query, we used to get results only for previous month, not for the date range(its not accepting the double quotes ("") for the number, when I remove "". its not accepting the string :(..

query we used for reference...

---

First of all, WHAT is not accepting what?  Are you talking about an editor in Splunk Answers (this forum), a Splunk UI, a Splunk dashboard, or Splunk search window, or SPL?  What does "not accepting" mean?  Does the UI give you some error message?  Does Splunk give an Error?  Or you are expecting one output and Splunk gives a different output? If so, what is the input, what is the context, what is the expected output and why do you expect that output in this context?

Second, let me try to interpret your question: You are saying that a user sees different results when using these selections in Splunk's pre-defined time selector:

1	"Previous month" in "Presets"
2	"Between" selector in "Date range"

Is this accurate?  What is relationship between that SPL snippet and Splunk's time selector, or your dataset?

[subitha_kennedy]

ok,Will try to explain..

Actually, we are having predefined time range filter as "previous month" in time filter..

previous month= -1mon@mon and @mon .(ex: august month)

When I am loading the dashboard, I am able to see different data and user from different location, they used to see different data. becoz of -1mon@mon condition used in the time range filter..(taking different epoc time, as starting day of me and other location user is different).

So, we tried to use the below query,

| eval lnum=if(match("1690848000","^[@a-zA-Z]+"),"str","num"), enum=if(match("1688169600","[a-zA-Z]"),"str","num")
| eval latest=case(isnum(1690848000),(1690848000-60),"1690848000"="now",now(),"1690848000"="",now(),lnum!="str","1690848000",1=1,relative_time(now(), "1690848000"))
| eval earliest=case(isnum(1688169600),(1688169600-60),"1688169600"="0","0",enum!="str","1688169600",1=1,relative_time(now(), "1688169600"))

In this query, if I use without isnum condition , it is working for previous month( same for all location users), if i include isnum condition , its not working. Becoz, isnum is not accepting double quotes(isnum(123), not isnum("123")) and previous month condition(1mon@mon, @mon) is not accepting without double quotes.

This the issue we are facing,

Can you pls suggest any change in query or any suggestions to fix this?? @yuanliu 

And also one other query(for other requirement), how can remove the presets from time range filter?

Highly appreciated if this issue got resolved 🙂

[yuanliu]

Let me describe a different scenario.  Suppose you do nothing, and use whichever time marker you already have (and I understand even less why you want to invent your own instead of using Splunk's built-in time selector - you can customize the selector any way you want, too).  Use it for the entire world.  Simply ask your users to set their preference to UTC in their own preferences.  Would that work?

From user.prefs:[general]

tz = <timezone>
* Specifies the per-user timezone to use.
* If unset, the timezone of the Splunk Server or Search Head is used.
* Only canonical timezone names such as America/Los_Angeles should be
  used (for best results use the Splunk UI).
* No default.

Your users do not need to edit the file, of course.  The time zone can be set from Splunk Web.

[PickleRick]

Yes, that's a feature, not a bug 😉

But seriously, Splunk internally stores and processes time as a so-called "unix timestamp" which contains number of seconds since midnight Jan 1st 1970. That timestamp does not change regardless of where the users is located an what timezone the user has set in his preferences.

But the timezone is rendered according to user's preferences-set timezone. Which means that the same _time field from the event (or any other field on which you do strftime() or format) will be rendered differently for different users.

Furthermore, the timerange selections are interpreted according to your local user's timezone which means that @d will mean something different depending on whether it's CET, BST, EST or whatever you can come up with.

As far as I remember, there is no support for specifying a timezone definition directly in a timerange specification parameters so you need to "cheat".

One possible walkaround (but a bit ugly I admit)is to use a subsearch (possibly packed into a macro) to render a timestamp in your local timezone, cut the timezone part, then append the given timezone spec and then parse the time string back to unix timestamp to get your earliest/latest value as integer. Very very ugly but it should work.

[yuanliu]

Are you talking about a user preference issue or an issue in ingested data?  If data is in UTC, your user can always select UTC as their UI preference; if your application logs in a local zone AND includes zone info in data, Splunk internally still uses UTC.

If data is in a different time zone but lacks zone info, that's a really bad situation.  There are several documents about how to configure time correctly.  A good place to start is Configure timestamps.  Hope this helps.