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!

Enterprise Security Content Update (ESCU) | New Releases

In December, the Splunk Threat Research Team had 1 release of new security content via the Enterprise Security ...

Why am I not seeing the finding in Splunk Enterprise Security Analyst Queue?

(This is the first of a series of 2 blogs). Splunk Enterprise Security is a fantastic tool that offers robust ...

Index This | What are the 12 Days of Splunk-mas?

December 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...