Asteroid Results from the current (or closest) date

[Nick Field]

A flaw (one of many flaws) in our returned JSON is that it often doesn't include asteroid results for the current date.

It would be cool if our application properly dealt with this, inside of the firstDictList function...

If this function were to check the keys in the Dict, and properly find the key which is closest to our current date stored in the model (which is stored shortly before making the NASA get request), then we could confidently say to the user 'Sorry, we don't exactly have results for todays date as such BUT here are results for tomorrows asteroids and that's as close as you'll get to todays results (if there were any)'....

So for example, if our firstDictList function could behave like this;

current date = '2017-03-13'

dict = 
'2017-03-09',  []
'2017-03-10',  []
'2017-03-11',  []
'2017-03-12',  []

firstDictList return value = [] from '2017-03-12' key

Because '2017-03-12' would be the nearest key to our models date.

There may be cases where the function may not know which key to use though...

current date = '2017-03-12'

dict = 
'2017-03-10',  []
'2017-03-14',  []

firstDictList return value = ???

Here, both date keys have a difference of two days between the current date. Which date key should be used?

The answer is of course the latter date; '2017-03-14'. Because in the event that some asteroids are only several miles away from Earth, we should let people know in advance that the asteroids will be here colliding into Earth tomorrow, rather than telling them about yesterdays news.

For a future feature, if we discover that 1 day from today, there will be an asteroid that has a miss distance of 0 from Earth, we should definitely update the view in an interesting (and catastrophic) way.