Getting Data In

Future Request: Epoch Time Correction

to4kawa
Ultra Champion
| makeresults
| eval time=-62167252739
| eval _time=time
| eval time_text=strftime(_time,"%c %::z")

-62167252739 is my negative epoch time limitation.
I don't know why.
-62167219200 is "0000/01/01 00:00:00 +0000" .
the diff is 9*60*60 + 18*60 + 59 .
my result is

_time   time    time_text
0000/01/01 00:00:59 -62167252739    Sat Jan  1 00:00:00 0000 +09:18:59

my TZ=JST(+09:00).
Is this problem only JST?
Hopefully it will be fixed.

my splunk is ver 8.0.1 on macosx 10.14.6.
On Terminal , date -r -62167252739 is 0000/01/01 00:00:00 LMT
As this result, This may not splunk problem, maybe.

0 Karma

nickhills
Ultra Champion

I'm not 100% clear on what you are asking, however

The Epoch or Unix Timestamp was originally designed to use a signed 32bit integer number, which gives a range of 136 years, with 1970 in the middle.
This means that the earliest you can represent with such limitations is 1901-12-13 20:45:52UTC
It also means you can expect issues in January 2038.

Trying to do conversions with dates prior to that is dependent on whether your system is using expanded time and 64bit values.
Wouldn't it be nice if there was a standard? - And of course there is... several of them:
https://en.wikipedia.org/wiki/Unix_time

Ultimately exactly how epoch dates are handled (particularly in the past) is implementation specific, so normal warnings apply.

I guess from a Splunk perspective - if you have machine data from much before 1901 you probably have some explaining to do!

Also - doing relative calculations (in seconds) with timezone offsets is confusing! Its much simpler to do it in UTC

If my comment helps, please give it a thumbs up!
0 Karma

nickhills
Ultra Champion

Look at this - note the warning about dates prior to 1752!

alt text

Not exactly sure what factors affect the calculation - could it be compensation for leap seconds in the epoch-string conversion?

Standards!

If my comment helps, please give it a thumbs up!
0 Karma

to4kawa
Ultra Champion

Thanks, @nickhillscpl
This result is also interesting.
Both are GMT, but the time is different.

The problem is the difference between _time and strftime() .

That said, it's probably not a problem in practice, as my analysis only pertains before 1870.

I think that different mechanisms may have an impact in the future.

0 Karma

to4kawa
Ultra Champion

Thanks for replay. I change TZ to UTC

| makeresults 
| eval time=-62167219200 
| eval _time=time 
| eval time_text=strftime(_time,"%c %::z")  

my result:

_time   time    time_text
0000/01/01 00:00:59 -62167219200    Sat Jan  1 00:00:00 0000 +00:00:00

I am cursed.

0 Karma

nickhills
Ultra Champion

I have to submit a new answer to upload image.

If my comment helps, please give it a thumbs up!
0 Karma

Azeemering
Builder

Hi,

I don't understand your logic? Since it is an epoch it is not a fixed time. The result of an epoch time of -62167252739 is different every second you run it.
The Unix epoch (or Unix time or POSIX time or Unix timestamp) is the number of seconds that have elapsed since January 1, 1970

to4kawa
Ultra Champion

Hi, @Azeemering
I have a mistake. please check my question.
anyway, strftime can handle negative, but strptime can't.

0 Karma
Get Updates on the Splunk Community!

What’s New in Splunk App for PCI Compliance 5.3.1?

The Splunk App for PCI Compliance allows customers to extend the power of their existing Splunk solution with ...

Extending Observability Content to Splunk Cloud

Register to join us !   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to ...

What's new in Splunk Cloud Platform 9.1.2312?

Hi Splunky people! We are excited to share the newest updates in Splunk Cloud Platform 9.1.2312! Analysts can ...