Why time range picker on default Splunk 6.1.x UI shows "Earliest time cannot be greater than latest time" errors?

[wpreston]

The time range picker on the default Splunk UI shows the

Earliest time cannot be greater than latest time

error, even though the time ranges entered are valid. For example, if I go to the Relative tab and set the Earliest to 7 days ago and the latest to now, I get the "Earliest time cannot be greater than latest time error" message. This happens both on my admin account and on my users accounts.

However, if I stay in the Presets section and click on the "7 days ago" preset it works correctly. It also works correctly if I specify earliest and latest in the search string. It's just in the Relative, Date Range, Date & Time Range, or Advanced sections where it doesn't work.

How can I fix this?

Edit: More information

So this is weird, I'm getting failures on some but not all settings in the relative tab:

• 7 seconds ago - FAIL
• 7 minutes ago - PASS
• 7 Hours ago - PASS
• 7 Days ago - FAIL
• 7 Weeks ago - FAIL
• 7 Months ago - FAIL
• 7 Quarters ago - FAIL
• 7 Years ago - FAIL

If I try using 6 instead of 7:

• 6 seconds ago - PASS
• 6 minutes ago - PASS
• 6 Hours ago - PASS
• 6 Days ago - FAIL
• 6 Weeks ago - FAIL
• 6 Months ago - FAIL
• 6 Quarters ago - FAIL
• 6 Years ago - FAIL

The error message I'm getting on the failures is always the "Earliest time cannot be greater than latest time" message.

[vhallan_splunk · Accepted solution]

This bug SPL-90600 has now been fixed in our latest release:

http://docs.splunk.com/Documentation/Splunk/latest/ReleaseNotes/6.1.4#Highlighted_Issues

[bosburn_splunk]

Just to expand on what Vinay posted:
If you are running 6.0.x or 6.1.x, you will have to upgrade to 6.1.4 to fix this issue.
If you are running 5.x, you can upgrade to 5.0.10 to fix this issues.

If you have any questions, please let me know.

[bosburn_splunk]

Update to the bug

All,
Here is the latest on this bug. When a date is selected in the GUI time range picker, we send the date to the backend (splunkd) in the in the format (mm/dd/yyyy). The backend then converts it to epoch time and returns the epoch time to front end (splunkweb). The front end then validates that the earliest time is truly earlier then the latest time.
What happened is that on Saturday, 09/06/2014 - we passed a magic point where the epoch time returned 1410065408, which is (10^10)%(2^32). Due to a bit of difference between the way Windows handles unsigned integers (it considers them 32 bit vs 64 bit), the value passed was being truncated.
So all in all, what does this impact?

Any 32-bit install of Splunk - Windows & Linux
64-bit installs of Splunk - Windows

This includes versions 5.x,6.x, and 6.1.x of Splunk.

The developers are looking at creating a patch for this - I will let you know once we have a better time frame.

Brian

[drmed]

There is an RSS feed you can subscribe to that will notify when the next release is available (6.1.4):
http://www.splunk.com/page/release_rss

[wpreston]

Any update on the time frame for the fix for this?

[dmr195]

It is not only the time picker that is affected - see http://answers.splunk.com/answers/168371/problem-with-rest-api-results-since-7th-september.html

Will bug SPL-90600 cover fixes to all the affected parts of Splunk?

[wpreston]

Received this email from Support:

This is a known issue (Bug SPL-90600) and is being investigated by the developers. What is being recommended as a work around is to add the "earliest= and latest=" commands to the search query.

Regards,

Brian

We had already begun using the workaround so we will just continue to do so for now. The workaround makes dashboards with time range pickers a bit more difficult to run, though.

Hopefully this issue will be resolved soon!

[natdsuarez]

What is the syntax for using earliest= latest=? I cannot get this workaround to work for us.

[kavraja]

Had the same problem and if you want to specify the exact dates to search between then you can use:

earliest=09/10/2014:0:0:0 latest=09/25/2014:0:0:0

It doesn't work without the ":0:0:0"

[natdsuarez]

I am running in a distributed environment (1 Search Head, 2 Indexers). None of these solutions work for me. Is anyone else running in a distributed environment? Do these solutions work for them? I have tried with and without quotes around the date/time. I have tried using 0:0:0 and 00:00:00. I have tried only using earliest. I have restarted both the indexers and the search head. My search string: index="index_name" | lookup local =1 userstatus UserID as user_id OUTPUTNEW UserStatus as user_status | eval MB = bytes/1024.00/1024.00 | search user_status = true file=search earliest = "09/01/2013:00:00:00" latest="09/25/2014:00:00:00" The search returns over 4,000 events for "All time" and 0 for any of the date combos attempted. No error is returned.

Apparently earliest and latest must be the first args after index=index_name. Thankfully, I will only require a bazillion hours to update all my reports

[nwieseler]

Correct - you need to throw the earliest/latest stuff before the first |...

Nick

[nwieseler]

Nice - much easier than my way 🙂

Nick

[nwieseler]

If you want to use two days ago you'd use the following in your search:

earliest=-2d@d latest=-1d@d

This would give you events the entire day of the day two days ago.

The -2d is how many days back. The @d "snaps" to the whole day if that makes any sense. You can use other units like seconds (s), minutes (m), hours (h), etc.

Nick

[nwieseler]

This is killing me... If there is a hotfix or anything (beta) I'd love to get this fixed instead of waiting for the whole point release...

Nick

[DanielFordWA]

I agree. This is also killing me!

The workaround of earliest= latest= doesn't work for me, tried both absolute and relative time modifiers. Scheduled reports are failing, data dumps to csv are failing and I cant even seem to do them manually.

Do we have a date for a fix? I need to set expectations.

Dan

[nwieseler]

I got this on Tuesday and they closed the case right away and I was unable to reply:

Nick,
This information has not been made available to support as of yet . That's all the information that we have .
Regards,
Charles

I got this after emailing another engineer on a case I had open later on in the day Tuesday:

Hi Nick,
6.1.4 should be out early Oct.
PM decided to include that fix as part of the maintenance release and not create new patch.
Best Regards,
Michal.

Hope this helps.

Nick

[DanielFordWA]

Restarting Splunk has enabled the work around to work.

[wpreston]

Update:

I received the following email from support:

The issue with the date range picker has been identified as SPL-90600 and will be fixed in the following releases:

6.1.4

6.0.7

5.0.10

Nothing yet as to when they might be released, though.

[las]

I agree with you on the flakiness, I am able to overtype the date, and pick it from the calender pop up, but when I press Apply, it reverses to 2001 again. Hopefully it will be resolved soon.

[davebrooking]

A further test and this time the restart didn't resolve the issue. However, I was able to overtype the 2001 with 2014 in the date box and I also used the calendar pop up to select the appropriate date. This appears to have resolved the issue and I can search on the correct timerange again, but it all seems a little flakey.