topic Re: Future Request: Epoch Time Correction in Getting Data In

Future Request: Epoch Time Correction

to4kawa — Sat, 08 Feb 2020 09:42:25 GMT

| 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.

Re: Future Request: Epoch Time Correction

Azeemering — Tue, 11 Feb 2020 10:07:03 GMT

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

Re: Future Request: Epoch Time Correction

to4kawa — Wed, 12 Feb 2020 09:27:47 GMT

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

Re: Future Request: Epoch Time Correction

nickhills — Sat, 15 Feb 2020 10:18:12 GMT

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

Re: Future Request: Epoch Time Correction

to4kawa — Sat, 15 Feb 2020 10:51:53 GMT

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.

Re: Future Request: Epoch Time Correction

nickhills — Sat, 15 Feb 2020 11:54:33 GMT

I have to submit a new answer to upload image.

Re: Future Request: Epoch Time Correction

nickhills — Sat, 15 Feb 2020 11:57:49 GMT

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

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

Standards!

Re: Future Request: Epoch Time Correction

to4kawa — Sat, 15 Feb 2020 22:03:49 GMT

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.