Splunk Enterprise

Need Help With time conversion and adding Timezone

coldwolf7
Explorer

Hello,

I need some help. Manipulating time is something I have struggled with 

Below is the code I have 

 ((index="desktop_os") (sourcetype="itsm_remedy")) earliest=-1d@d
| search ASSIGNED_GROUP IN ("Desktop_Support_1", "Remote_Support")
``` Convert REPORTED_DATE to epoch form ```
| eval REPORTED_DATE2=strptime(REPORTED_DATE, "%Y-%m-%d %H:%M:%S")
``` Keep events reported more than 12 hours ago so are due in < 12 hours ```
| where REPORTED_DATE2 <= relative_time(now(), "-12h")
| eval MTTRSET = round((now()-REPORTED_DATE2)/3600)
| dedup INCIDENT_NUMBER
| stats values(REPORTED_DATE) AS Reported, values(DESCRIPTION) AS Title, values(ASSIGNED_GROUP) AS Group, values(ASSIGNEE) AS Assignee, LAST(STATUS_TXT) as Status,values(MTTRSET) as MTTRHours, values(STATUS_REASON_TXT) as PendStatus by INCIDENT_NUMBER
| search Status IN ("ASSIGNED", "IN PROGRESS", "PENDING")
| sort Assignee
| table Assignee MTTRHours INCIDENT_NUMBER Reported Title Title Status PendStatus 

this code runs and gives us the results we need, but the issue is that REPORTED_DATE field is off by 5 hours due to time zone issue. that is a custom field from out ticketing system that is stuck on GMT and the output looks like 

2024-01-08 09:22:49.0

I need to get that field produce a correct timezone for EST. I am struggling with making it work.

I looked at this thread but that is not working for us: Solved: How to convert date and time in UTC to EST? - Splunk Community

Any help is appreciated.

 

Thanks

 

Labels (2)
0 Karma
1 Solution

dtburrows3
Builder

First off, I would suggest doing what @sshelly_splunk said if possible. If not possible then you can try this method with SPL.

I see this question come over a lot and people usually respond with "its complicated", and it is.
With that said, I have been working on trying to standardize a solution by using macros and think I have a good first iteration worked out, but I'm sure still needs some more regression testing.

Here is what results look like using your sample timestamp that is assumed to be GMT but because of the user running the query's timezone preference is set to something else the epoch conversion isn't working as expected.

dtburrows3_0-1704819247370.png


You can see inputs of the first macro `convert_timestamp_to_epoch(3)` are
$timestamp_field$ ----> REPORTED_DATE
$timestamp_format$ ----> %Y-%m-%d %H:%M:%S.%1N
$assumed_timezone$ ----> GMT
    This first macro should convert a timestamp to a standardized epoch time by using either a timezone found in the timestamp itself or if no timezone is found in the timestamp to revert to using the 3rd argument of the "assumed_timezone". You have the ability to leave the 3rd argument blank as well and then the catchall timezone is the user's configured timezone preference.

The second macro `convert_epoch_to_specific_timezone(3)` has the input args
$epoch$ ----> standardized_epoch (this is default fieldname of the output of the previous macro)
$timestamp_format$ ----> %Y-%m-%d %H:%M:%S.%1N
$output_timezone$ ----> EST
    This macro is taking in a epoch value and returns a human readable timestamp set to any timezone requested in the 3rd argument. (thats the idea at least)

Using the 2 macros together should be able to convert any timestamp to another with a desired timezone association.

If you are interested in the macros, shoot me a message and I can get them packaged up for you and share.

In the mean time why dont you try appending "+0000" to your REPORTED_DATE and convert to epoch including the timezone specifier
Example:

 

    | eval
        REPORTED_DATE2=strptime('REPORTED_DATE'."+0000", "%Y-%m-%d %H:%M:%S.%1N%z")

 

View solution in original post

sshelly_splunk
Splunk Employee
Splunk Employee

Do you have the ability to modify the sourcetype for the ticketing system data? 

You can add a single config to the input / sourcetype: 

# The following props.conf entry sets Eastern Time Zone if host matches nyc*.
[host::nyc*]
TZ = US/Eastern

Is your Splunk environment Splunk Cloud, or self-hosted? 

If cloud, you should be able to go to "Settings"->"Source Types", click on the specific sourcetype and add a key/value pair in the advanced section key="TZ", value ="US/Eastern" 

0 Karma

coldwolf7
Explorer

I do not have access to update that. So I was trying to figure out how to do it with SPL

0 Karma

dtburrows3
Builder

First off, I would suggest doing what @sshelly_splunk said if possible. If not possible then you can try this method with SPL.

I see this question come over a lot and people usually respond with "its complicated", and it is.
With that said, I have been working on trying to standardize a solution by using macros and think I have a good first iteration worked out, but I'm sure still needs some more regression testing.

Here is what results look like using your sample timestamp that is assumed to be GMT but because of the user running the query's timezone preference is set to something else the epoch conversion isn't working as expected.

dtburrows3_0-1704819247370.png


You can see inputs of the first macro `convert_timestamp_to_epoch(3)` are
$timestamp_field$ ----> REPORTED_DATE
$timestamp_format$ ----> %Y-%m-%d %H:%M:%S.%1N
$assumed_timezone$ ----> GMT
    This first macro should convert a timestamp to a standardized epoch time by using either a timezone found in the timestamp itself or if no timezone is found in the timestamp to revert to using the 3rd argument of the "assumed_timezone". You have the ability to leave the 3rd argument blank as well and then the catchall timezone is the user's configured timezone preference.

The second macro `convert_epoch_to_specific_timezone(3)` has the input args
$epoch$ ----> standardized_epoch (this is default fieldname of the output of the previous macro)
$timestamp_format$ ----> %Y-%m-%d %H:%M:%S.%1N
$output_timezone$ ----> EST
    This macro is taking in a epoch value and returns a human readable timestamp set to any timezone requested in the 3rd argument. (thats the idea at least)

Using the 2 macros together should be able to convert any timestamp to another with a desired timezone association.

If you are interested in the macros, shoot me a message and I can get them packaged up for you and share.

In the mean time why dont you try appending "+0000" to your REPORTED_DATE and convert to epoch including the timezone specifier
Example:

 

    | eval
        REPORTED_DATE2=strptime('REPORTED_DATE'."+0000", "%Y-%m-%d %H:%M:%S.%1N%z")

 

coldwolf7
Explorer

In the mean time why don't you try appending "+0000" to your REPORTED_DATE and convert to epoch including the timezone specifier

This was  perfect and worked great.

I am very interested in macros I have never done them can you help me build the ones out you did 

 

 

 

0 Karma

sshelly_splunk
Splunk Employee
Splunk Employee

I would suggest pinging the Splunk admins, as the data is coming in with an issue, and will always be an issue until they modify the input or sourcetype.

You can add/remove whatever number of hours you need for a particular _time field, but if it gets corrected in the future, all of your searches will fail. As well, I'm not sure how things would behave if you were to drilldown from a dashboard into raw data.

 

It really is a simple as adding that TZ key/value to the sourcetype. What that does is makes the display of the data with different timezones seamless to end users. For example, searching for the last 60 minutes data sets configured in GMT AND CST will correctly display to the end user if TZ is configured for the sourcetypes.

 

0 Karma
Get Updates on the Splunk Community!

Index This | Forward, I’m heavy; backward, I’m not. What am I?

April 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...

A Guide To Cloud Migration Success

As enterprises’ rapid expansion to the cloud continues, IT leaders are continuously looking for ways to focus ...

Join Us for Splunk University and Get Your Bootcamp Game On!

If you know, you know! Splunk University is the vibe this summer so register today for bootcamps galore ...