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!

Index This | Why did the turkey cross the road?

November 2025 Edition  Hayyy Splunk Education Enthusiasts and the Eternally Curious!   We’re back with this ...

Enter the Agentic Era with Splunk AI Assistant for SPL 1.4

  🚀 Your data just got a serious AI upgrade — are you ready? Say hello to the Agentic Era with the ...

Feel the Splunk Love: Real Stories from Real Customers

Hello Splunk Community,    What’s the best part of hearing how our customers use Splunk? Easy: the positive ...