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!

They're back! Join the SplunkTrust and MVP at .conf24

With our highly anticipated annual conference, .conf, comes the fez-wearers you can trust! The SplunkTrust, as ...

Enterprise Security Content Update (ESCU) | New Releases

Last month, the Splunk Threat Research Team had two releases of new security content via the Enterprise ...

Detecting Remote Code Executions With the Splunk Threat Research Team

REGISTER NOWRemote code execution (RCE) vulnerabilities pose a significant risk to organizations. If ...