API returns 404 "No data available" when asking for latest date

[jtbandes]

When I make an API call to https://api.nasa.gov/planetary/apod?api_key=DEMO_KEY right now (Thu, 01 Oct 2020 01:30:49 GMT) I get a 404:

{
  "code": 404,
  "msg": "No data available for date: 2020-10-01",
  "service_version": "v1"
}

It’s currently Sep 30 in my time zone, not Oct 1. I understand if the server wants to give me Oct 1’s image after midnight UTC, but if so it shouldn’t give me a 404.

I suspect that's because the "current date" default sometimes changes before the image is actually made available (due to time zone differences, maybe?):

apod-api/application.py

Lines 127 to 129 in a434768

	if not input_date:
	# fall back to using today's date IF they didn't specify a date
	input_date = datetime.strftime(datetime.today(), '%Y-%m-%d')

However it looks like there is already some code to handle this. So I guess that's not working properly:

apod-api/apod/utility.py

Lines 263 to 271 in a434768

	# handle edge case where the service local time
	# miss-matches with 'todays date' of the underlying APOD
	# service (can happen because they are deployed in different
	# timezones). Use the fallback of prior day's date
	if use_default_today_date:
	# try to get the day before
	dt = dt - timedelta(days=1)
	return _get_apod_chars(dt, thumbs)

[gumbarros]

I'm having this issue right now

[jtbandes]

Yeah, it happens every evening when the date changes. (Edit: at least I've noticed it for a couple days in the past week.)

[ibll]

I’ve never had it happen like this.

[gumbarros]

Client-side solution:

https://github.com/gumbarros/kepler/blob/master/lib/src/services/api/api.dart#L38

[jtbandes]

My workaround (above) is to request a date range starting from yesterday and using the last item in the returned list. I don't include the end_date because an end_date of tomorrow returns a 400 error 😕

[nwunderly]

I had been wondering about this myself. Found it when my code started crashing at exactly 8pm EDT. I assumed it was intentional but couldn't imagine why the date parameter, when left out, defaulted to "today UTC" and not "most recent valid date". Would certainly make things easier for users.

[kmpoppe]

I'm using the APOD API in Cypht (https://github.com/jasonmunro/cypht) and found it morning, that there was no new picture at 04:30am CET but at 06:30am - after a quick glance at nasa.gov it seems that they format all their times in EST/EDT.
I have now changed the module to just calculate what day it is in EST - and just not request the "current" day my server has. A quick mail to Robert Nemiroff (one of the creators of APOD) confirmed this idea.
So my guess is, that this is by design and won't be fixed - even though I think that providing the "next" day would do no harm.
Just as a reminder, the archive accessible at https://apod.nasa.gov/apod/archivepix.html also doesn't list the next day and guessing the URL of the next day results in a 404 - so the whole APOD would need to be prepared for always providing the next day information.

[elementh]

@kmpoppe I'm doing the same in a wrapper I'm preparing . Seems to be the only plausible solution :/

[kmpoppe]

@elementh I've linked my PR for the Cypht project. Maybe you can find some inspiration there.

[elementh]

@kmpoppe I will, thank you very much!

[nwunderly]

#51 should have fixed this issue, no?

[elementh]

but that means having specific code to handle a whatever means "today" for the user and erase that from the request.

#51 It's helpful but can still can't handle every case.