Hi. We recently upgraded from a 4.2 installation to 4.3.3 and a report that includes the _time field (which used to come out in epoch format) now displays the field as a formatted string.
I have changed nothing with the query. It has always been a search | timchart | eval (to rename a field) | fields _time,some,other,fields
That's all! No formatting, etc.
The _time value used to look like this: 1341288000
Now shows up like this, including the quotation marks (this is not from the same number though!): "2012-07-24 00:00:00.000 EDT"
Someone recently asked how to get epoch time, and the answer was to reference _time but as you can see. that has ceased to work for me!
Anyone know about this? The documentation still says this:
"The _time field is stored internally in UTC Format. It is translated to human-readable Unix time format when Splunk renders the search results (the very last step of search time event processing)."
I noticed this, as you used to have to format _time to be human readable as well.
However now, when generate data in tabular format with _time it shows as ascii human-readable. However when I rename the field from _time to something like Time it shows up as epoch. I then have to use eval to rearrange it.
You can try renaming the field.
I noticed this, as you used to have to format _time to be human readable as well.
However now, when generate data in tabular format with _time it shows as ascii human-readable. However when I rename the field from _time to something like Time it shows up as epoch. I then have to use eval to rearrange it.
You can try renaming the field.
Depending where you see this, it may or may not be considered a bug. Certainly in the Web UI and in the CLI tools, it has rendered human-readable and time-zone corrected, and that would not be a bug. But if you're using the API or exporting to a file or something, then I would say that _time should remain as UTC epoch seconds.
Thank you very much. This does work. I'm in contact with Splunk regarding this as well, so they know about this issue.