Splunk Search

converting 1.1.1970 to epoch doesn't work, whereas converting epoch 0 to string does work... is it a bug or did I miss something?

grundsch
Communicator

Hi,
I stumbled on something funny with the time conversion functions. Trying to convert the 1st of January 1970 to epoch (should be zero) does not work (as any other day in 1970). Only from 1.1.1971 does the conversion work. The other way around does work, i.e. epoch 0 to string does produce 01.01.1970:

 index=* | head 1 | eval test_nok="01.01.1970" | eval test_ok="1.1.1971" | eval test_epoch=0
| eval test_strp_nok=strptime(test_nok, "%d.%m.%Y") | eval test_strp_ok=strptime(test_ok, "%d.%m.%Y") 
|  convert timeformat="%d.%m.%Y" mktime(test*ok)| convert timeformat="%d.%m.%Y" ctime(test_epoch)
| table test*

Output:

|test_epoch|    test_nok|   test_ok|    test_strp_ok    |
|01.01.1970|           |31532400   |    31532400.000000 |
                    ^--conversion of 01.01.1970 failed

Any idea why?

Tags (3)
1 Solution

dmr195
Communicator

Is your Splunk server set to central European time? The Unix epoch is midnight on 1.1.1970 UTC. The UTC bit is very important because obviously for most of the world that corresponds to a time other than midnight in local time.

Your conversion of 1.1.1971 maps to 31532400, but 86400 * 365 is 31536000. So it seems that midnight 1.1.1971 in your time zone was 11pm 31.12.1970 in UTC. Therefore midnight 1.1.1970 in your time zone would have been 11pm 31.12.1969 UTC, which is before the Unix epoch.

However, having said all that it does look like Splunk's strptime() eval function refuses to work with any date in 1970. Even after changing your search to set test_nok="31.12.1970" it still fails to convert. It only starts working at "1.1.1971". So maybe it's best to avoid all dates in 1970 if you're using Splunk.

View solution in original post

dmr195
Communicator

Is your Splunk server set to central European time? The Unix epoch is midnight on 1.1.1970 UTC. The UTC bit is very important because obviously for most of the world that corresponds to a time other than midnight in local time.

Your conversion of 1.1.1971 maps to 31532400, but 86400 * 365 is 31536000. So it seems that midnight 1.1.1971 in your time zone was 11pm 31.12.1970 in UTC. Therefore midnight 1.1.1970 in your time zone would have been 11pm 31.12.1969 UTC, which is before the Unix epoch.

However, having said all that it does look like Splunk's strptime() eval function refuses to work with any date in 1970. Even after changing your search to set test_nok="31.12.1970" it still fails to convert. It only starts working at "1.1.1971". So maybe it's best to avoid all dates in 1970 if you're using Splunk.

grundsch
Communicator

yes, yes, and yes! 🙂
My server is indeed CET, but as you mentionned, any date in 1970 fails.
It still looks like a bug to my eyes. 😉

akocak
Contributor

Until I found this post, I regexed timestamp to different pieces , building a different format from that , trying different strptimes tests. All ended up in this post 🙂

0 Karma
Get Updates on the Splunk Community!

What's New in Splunk Enterprise 9.4: Features to Power Your Digital Resilience

Hey Splunky People! We are excited to share the latest updates in Splunk Enterprise 9.4. In this release we ...

Take Your Breath Away with Splunk Risk-Based Alerting (RBA)

WATCH NOW!The Splunk Guide to Risk-Based Alerting is here to empower your SOC like never before. Join Haylee ...

SignalFlow: What? Why? How?

What is SignalFlow? Splunk Observability Cloud’s analytics engine, SignalFlow, opens up a world of in-depth ...