This event correctly gets logged as happening at noon eastern, then I display it using my splunk server in the mountain time zone, it shows up as happening at 10:00 (which is correct). Let's say something happened at noon eastern time (-4:00). Your solution simply changes the time, then displays this incorrect time in the "local" timezone so it appears correct. I too am attempting to view a report and have the times show up in a different time zone. Maybe better Splunkers can make a more elegant set of commands, but this appears to work for me.
Output (reports) can now use newstrtime as human-readable localized time for machine-readable purposes (like sorting or timecharts) you can use newctime.
If your original timestamp fields are in some other timezone, just change "UTC" to whatever your timezone value is. | eval newstrtime = strftime(newctime,"%Y-%m-%d %T") | eval newctime = strptime(origtime,"%Y-%m-%d %T %Z") To be clear, my log's indexed timestamps are processed correctly, but each event additionally has three more date-time fields that are input in UTC, and I would like to output them in local time.Īfter searching for a long time through SplunkBase and the documentation with no results, I believe I've figured out a solution on my own.Īssuming original time field origtime is in format %Y-%m-%d %T and is in UTC (but has no timezone notation in the original string): I had this problem as well I have events that contain multiple time fields, and sometimes I want to sort those events based on, or otherwise display, time fields that are NOT the event's timestamp, and show those times in local time for human consumption. I know this question is old, but it has 27K views, and no verified answer, and is the top SplunkBase result when I search "change timezone at search time," so it seems like it's still relevant. Worse, the method is in essence hardcoding the output expectation for the time zone (PST versus PDT), so the report results will be presenting a time zone that is not actually in effect during half the year. It will get the wrong answer for a couple of hours each year when the calculation is performed across the hours that the time is changing to and from daylight savings. The method is for display only, not for changing the underlying data. Set the values of myDateFormat and myTzName as desired. It then applies whatever the difference in seconds was to the original time, then formats the result with the local time zone at the end. This takes the relevant time UTC, pretends it is local, then translates it back to UTC. | eval localDisp=strftime(2*_time-strptime(strftime(_time,myDateFormat." ".myTzName),myDateFormat." %Z"),myDateFormat)." ".myTzName | eval TimeDisp=strftime(_time,myDateFormat." %Z") | rename COMMENT as "The above just gets a couple of records for demonstration purposes." And you don't even know if the source is reporting the time properly.Here's one way. So you might get different results depending on when you're calling your search and you'll never know which results are proper ones. Without a timezone information within the time string you don't know whether it was in "summer time" or "winter time".
But it might mean that daylight saving comes into play. Remember that if you're evaluating your search, it's parsing the time according to your user's configured timezone, which might not be a problem if you assume that none of your users will be far enough to warrant a different timezone. I'd strongly advise to reconfigure your sources so that they do include the timezone information within the timestamp.
Or even, if you can enumerate hosts or sources with/without timezone, you could make a conditon based on that field. You could - since you're saying that only some subset of your events contains the timezone - do a conditional evaluation like | eval mytime=if(like(match(mytime,".*-+$"),strptime(mytime,"format with timezone"),strptime(mytime,"format without timezone") More than one time-based field in the event can cause confusion
0 kommentar(er)
