I have a string from a complex JSON event providing an ISO 8601 date/time in UTC. I want to convert it to the local time zone, in this case CST or CDT. The computer knows its timezone and keeps its clock adjusted, so the timezone info is in there somewhere. After hours of search I can find no way that Splunk can perform this simple operation. strptime() gets me half way there, but there is no general, portable way to do the appropriate timezone adjustment.
This has nothing to do with the event timestamps! The timestamps I'm converting are different from those. All I'm looking for is simple date/time processing supported by virtually every programming language in existence...
| makeresults
| eval UTC_string="Mon Jul 13 09:30:00 2017 +0000"
| eval UTC=strptime(UTC_string,"%c %z")
| eval local_time=strftime(UTC,"%+")
Hi @jkotula
There are the references.
Common time format variables
Daylight Saving Time and Time Zones in Europe
does-tz-setting-account-for-daylight-savings-time
%z
is offset variables.
Changing UNIX time to a time string will basically be local time.
Wouldn't it work if I passed the offset value to strptime
according to the format, as in my example?
UTC format doesn't have the offset in all cases. In my case, I'm looking at JSON output generated by the Newtonsoft library in C#.
| makeresults
| eval json_time_text="2020-01-05T13:15:30"
| eval time=strptime(json_time_text." +0000","%FT%T %z")
| eval local_time=strftime(time,"%FT%T %z")
Why don't you modify the time string when searching?
Because I don't know the timezone offset. That's the whole issue.
I admit time zones are not my strong suit, but does this get you closer?
| makeresults
| eval UTCtime="2020-01-05T13:15:30Z" | fields - _time
| eval epochTime=strptime(UTCtime,"%Y-%m-%dT%H:%M:%S.%Q")
| eval mySecondsOffset=abs(tonumber(strftime(epochTime,"%:::z")))*60*60
| eval localTimestamp=strftime(epochTime-mySecondsOffset,"%Y-%m-%dT%H:%M:%S")
Not really. The whole problem is that I don't know the offset, particularly with DST.
What do you mean "sample"? User preference isn't the issue -- I'm using the date to look up something in a lookup table.