Not able to get rid of EDT timezone using strftime command 2022-04-07 07:00:11.028-EDT . Any suggestions
is this what are you looking for ?
Try this run anywhere search:
| makeresults | fields - _time | eval Time="2022-04-07 07:00:11.028-EDT" | eval time=strftime(strptime(Time, "%Y-%m-%d %H:%M:%S.%3Q-%Z"),"%Y-%m-%d %H:%M:%S.%3Q")
Can you be a bit more specific on what you mean by get rid of the timezone?
If you want to render the timestamp without the zone info just give a format without the zone specifier to the strftime() call.
If you want Splunk to return a representation of a timestamp in a timezone different from the one you have in your user's settings there's no way to do so (you can cheat a bit by shifting the timestamp manually but that doesn't count since it's not the timestamp in different zone but another timestamp).
Batch job logs has 2022-04-07 07:00:11.028-EDT as transmission time and none of the other logs print timezone so for consistency wanted to remove EDT timezone from the output when populated in table on my sftp transmission dashboard.
Well, typically you'd want to parse the time and use the _time field anyway so where's the problem? 😉
But seriously, the most important thing is that however many sources you have, the date is properly parsed and the timestamp that you get in your _time field is consistent with the actual time the event happened. If it is, then you probably do some summaries, tables and so on based on a set of fields, not on raw event data. If you want raw event data, you can't modify it after it's been ingested. It's there and it's gonna stay that way. You can try to cut it in search time but there's not much point.
So the question is whether you want to display the time as a field or whether you want to have the "-EDT" part cut from your raw event (which doesn't make much sense TBH).
I tried using_time field but i want the timing when the file transmission completed._time field gives the timestamp when the job started., to add our logs are not that friendly to pull data out of it.
Ok, that makes sense. More than one time-based field in the event can cause confusion 😉
But this creates a problem.
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,".*-[A-Z]+$"),strptime(mytime,"format with timezone"),strptime(mytime,"format without timezone")
or even, if you can enumerate hosts or sources with/without timezone, you could make a conditon based on that field.
I'd strongly advise to reconfigure your sources so that they do include the timezone information within the timestamp. 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. But it might mean that daylight saving comes into play. Without a timezone information within the time string you don't know whether it was in "summer time" or "winter time". So you might get different results depending on when you're calling your search and you'll never know which results are proper ones. And you don't even know if the source is reporting the time properly.