- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

Hi Splunkers,
Why the relative_time function is not converting +24y? any reason? Any way to achieve this?
|stats count | eval next_time=relative_time(now(),"+24y")
Is there any limitation in relative_time function?
Cheers!!!
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It seems that relative_time (at least on 6.2.0) is limited by the Year 2038 problem: http://en.wikipedia.org/wiki/Year_2038_problem
Check this out, this works:
noop | stats count | eval _time=relative_time(now(),"+24y@y+18d+3h+14m+7s")
But this doesn't:
noop | stats count | eval _time=relative_time(now(),"+24y@y+18d+3h+14m+8s")
But this does:
noop | stats count | eval _time=relative_time(now(),"+24y@y+18d+3h+14m+7s")+1
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
is there an update on this issue? what's an alternative solution?
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
we've fixed the issue by using good ol strptime and strftime
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It seems that relative_time (at least on 6.2.0) is limited by the Year 2038 problem: http://en.wikipedia.org/wiki/Year_2038_problem
Check this out, this works:
noop | stats count | eval _time=relative_time(now(),"+24y@y+18d+3h+14m+7s")
But this doesn't:
noop | stats count | eval _time=relative_time(now(),"+24y@y+18d+3h+14m+8s")
But this does:
noop | stats count | eval _time=relative_time(now(),"+24y@y+18d+3h+14m+7s")+1
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For those following along at home... as it's still a problem, I logged Case 468033 for this.
