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!

Webinar Recap | Revolutionizing IT Operations: The Transformative Power of AI and ML ...

The Transformative Power of AI and ML in Enhancing Observability   In the realm of IT operations, the ...

.conf24 | Registration Open!

Hello, hello! I come bearing good news: Registration for .conf24 is now open!   conf is Splunk’s rad annual ...

ICYMI - Check out the latest releases of Splunk Edge Processor

Splunk is pleased to announce the latest enhancements to Splunk Edge Processor.  HEC Receiver authorization ...