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!

Splunk Mobile: Your Brand-New Home Screen

Meet Your New Mobile Hub  Hello Splunk Community!  Staying connected to your data—no matter where you are—is ...

Introducing Value Insights (Beta): Understand the Business Impact your organization ...

Real progress on your strategic priorities starts with knowing the business outcomes your teams are delivering ...

Enterprise Security (ES) Essentials 8.3 is Now GA — Smarter Detections, Faster ...

As of today, Enterprise Security (ES) Essentials 8.3 is now generally available, helping SOC teams simplify ...