_time format

[benhooper]

Our data input contains two timestamp fields — creation_time and modification_time — both formatted in line with ISO 8601 (yyyy/mm/dd hh:mm:ss.ms).

Splunk parses modification_time as _time but, in doing so, it applies the system-default timestamp format, in our case the British one (dd/mm/yyyy hh:mm:ss.ms).

Is there any way that we can either:

1. Change the timestamp format of _time (not "eval time = _time" etc) so that they match?
   or
2. Hide or replace _time in search results, dashboard table panels, etc so that we can use the original, modification_time field instead?

[renjith_nair]

What happens when you just omit the _time from search result/dashboard panel by just adding

|fields - _time

[benhooper]

The column remains but the fields / cells / values are blank:

[stonefr33]

you can use the table command to choose the fields to display
| table creation_time, modification_time etc.

[benhooper]

That works for a search but not in the dashboard table panels, even when omitting _time from <fields>.

[stonefr33]

Is your visualisation 'Events' or 'Stats Table'? Should work for Stats table view but if that view doesn't work for you then you could cheat a little.

| eval _time = modification_time 

OR

You can play with the time formatting with eval strptime (convert to unixtime) and feed that to strftime (format it the way you want) , but it may be more hassle then its worth.

https://docs.splunk.com/Documentation/Splunk/8.0.5/SearchReference/Commontimeformatvariables

[benhooper]

Ah, it's an events table. Sorry, I forgot that there was another.

Unfortunately, "eval _time = modification_time " doesn't make a difference - the format stays the same. I supposed that's to be expected, though, as _time is originally derived from modification_time anyway. It's like _time has a hardcoded regional time format or something.

[stonefr33]

Does this work for you?

| eval _time=strftime(_time,"%F %H:%M:%S.%3Q")

[benhooper]

I'm afraid not. The format stays the same.

[stonefr33]

Sorry but that's all the tricks I know, not sure if there is something on the backend that can override it. Any of these recommendations I have sent have worked in my environment, but I'm not an admin so unsure of the backend wizardry.

Good luck

[benhooper]

Thanks anyway!

[benhooper · Accepted solution]

I found that it's only the Events Table that has a permanent _time column so I simply used a Statistics Table instead.