Dashboards & Visualizations

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

Motivator

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.

1 Solution

Splunk Employee
Splunk Employee

Splunk Employee
Splunk Employee

Splunk Employee
Splunk Employee

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.

Splunk Employee
Splunk Employee

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

Explorer

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

Motivator

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

0 Karma

Communicator

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?

0 Karma

Motivator

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!

New Member

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

0 Karma

Path Finder

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"

0 Karma

New Member

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

0 Karma

Path Finder

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

Nick

0 Karma

Path Finder

Nice - much easier than my way 🙂

Nick

0 Karma

Path Finder

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

Path Finder

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

0 Karma

Contributor

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

0 Karma

Path Finder

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

0 Karma

Contributor

Restarting Splunk has enabled the work around to work.

0 Karma

Motivator

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.

0 Karma

Contributor

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.

0 Karma

Contributor

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.

0 Karma
State of Splunk Careers

Access the Splunk Careers Report to see real data that shows how Splunk mastery increases your value and job satisfaction.

Find out what your skills are worth!