Splunk Search

Bug in convert ctime?

nekb1958
Path Finder

Hi

the following search

eval test=7200 | convert timeformat="%H:%M:%S" ctime(test) | table test

gives me 03:00:00
but (7200 = 3600 x 2) i expect 02:00:00 ! what goes wrong?
because i get the same result under 4.3.5 and 6.0 i cannot believe on a bug, so where is my mistake???

bye norbert

Tags (2)
0 Karma

nekb1958
Path Finder

NOT

eval test=7200 | convert timeformat="%H:%M:%S" ctime(test) | table test

that´s what i need

eval test=tostring(7200,"duration") | table test

0 Karma

Ayn
Legend

Which timezone are you in? Epoch is always represented in UTC, so if you're in a timezone that's UTC+1, then 7200 seconds in epoch will be translated as "7200 seconds since January 1st, 1970, + the system's timezone offset" which is 01/01/1970 03:00:00. You can check this behaviour in a UNIX system by doing "date -r 7200". On my system, which is in CET (currently UTC+1), this yields the following results:

# date -r 7200
Thu Jan  1 03:00:00 CET 1970

Whereas doing the same thing with the timezone set to UTC will output this:

# TZ=UTC date -r 7200
Thu Jan  1 02:00:00 CET 1970

Ayn
Legend

No problem. Could you mark my answer as accepted? Thanks!

0 Karma

nekb1958
Path Finder

ouch, yes. Thank you now i see my mistake. It´s not a time span it´s a date! and yes then the timezone is important. thanks!

0 Karma
Get Updates on the Splunk Community!

App Platform's 2025 Year in Review: A Year of Innovation, Growth, and Community

As we step into 2026, it’s the perfect moment to reflect on what an extraordinary year 2025 was for the Splunk ...

Operationalizing Entity Risk Score with Enterprise Security 8.3+

Overview Enterprise Security 8.3 introduces a powerful new feature called “Entity Risk Scoring” (ERS) for ...

Unlock Database Monitoring with Splunk Observability Cloud

  In today’s fast-paced digital landscape, even minor database slowdowns can disrupt user experiences and ...