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*
|test_epoch| test_nok| test_ok| test_strp_ok | |01.01.1970| |31532400 | 31532400.000000 | ^--conversion of 01.01.1970 failed
Any idea why?
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.
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. 😉
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 🙂