| 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.
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
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.
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.
I have to submit a new answer to upload image.
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
Hi, @Azeemering
I have a mistake. please check my question.
anyway, strftime
can handle negative, but strptime
can't.