No data available for date (perhaps due to time zone issues)

[andrejpodzimek]

Describe the bug

Refreshes end up with error 404. When trying HTTP directly (with my app key), I'm getting this:

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

To Reproduce

1. Set a time zone far enough ahead of NASA's time zone (so that there's a date difference).
2. Try a refresh.

Expected behavior

The date in the requests should be in NASA's favorite time zone.

Screenshots

• N/A

Operating system with version

• Arch Linux (no "version"; up-to-date as it should be)

GNOME Shell version

• 3.38.1

Installation method

• AUR

Logs

Oct 13 05:31:01 aether gnome-shell[249738]: NASA APOD extension: https://api.nasa.gov/planetary/apod?api_key=[[CENSORED]]
Oct 13 05:31:01 aether gnome-shell[249738]: NASA APOD extension error: Network error: HTTP status code 404.
Oct 13 05:31:01 aether gnome-shell[249738]: JS ERROR: Error: Source.notify() has been moved to Source.showNotification()this code will break in the future
                                            notify@resource:///org/gnome/shell/ui/messageTray.js:794:23
                                            notifyError@/usr/share/gnome-shell/extensions/nasa_apod@elinvention.ovh/notifications.js:48:16
                                            _refresh/makeRequest</<@/usr/share/gnome-shell/extensions/nasa_apod@elinvention.ovh/extension.js:391:35
Oct 13 05:31:01 aether gnome-shell[249738]: NASA APOD extension: Next check @ local time 05:41
Oct 13 05:31:01 aether gnome-shell[249738]: NASA APOD extension: Refresh done.

Extension's settings

Please paste below the entire output of
gsettings --schemadir ~/.local/share/gnome-shell/extensions/nasa_apod@elinvention.ovh/schemas/ list-recursively org.gnome.shell.extensions.nasa-apod.

Nope, that doesn't exist:

Could not load schemas from /home/andrej/.local/share/gnome-shell/extensions/nasa_apod@elinvention.ovh/schemas/: Failed to open file ?/home/andrej/.local/share/gnome-shell/extensions/nasa_apod@elinvention.ovh/schemas/gschemas.compiled?: open() failed: No such file or directory

[andrejpodzimek]

For the record, the URL appears to accept a date GET parameter and the request returns something meaningful with a date that NASA knows about.

[Elinvention]

The contacted URL is in the log and there is no need to specify a date. If it's not specified it is assumed to be the latest day available. For some reason the request returned error 404 which means not found. Try to access this url with your browser and key https://api.nasa.gov/planetary/apod?api_key=[[yourkey]]. It should load a JSON document with status 200.

BTW I'm glad someone put the extension on the AUR. However in that case the extension is not installed in your home directory, but system wide under /usr/share/gnome-shell/extensions/nasa_apod@elinvention.ovh/. So the last command should be gsettings --schemadir /usr/share/gnome-shell/extensions/nasa_apod@elinvention.ovh/schemas/ list-recursively org.gnome.shell.extensions.nasa-apod.

Thank you for this detailed bug report.

[andrejpodzimek]

The contacted URL is in the log and there is no need to specify a date. If it's not specified it is assumed to be the latest day available. For some reason the request returned error 404 which means not found. Try to access this url with your browser and key https://api.nasa.gov/planetary/apod?api_key=[[yourkey]]. It should load a JSON document with status 200.

Until 06:00 it returned JSON data with date= and api_key= specified, 404 otherwise (with api_key= alone). From 06:00 on it returned JSON data all the time.

Because 6 hours is the timezone difference from CEST and the closest USA time zone, this lead me to believe that it had been a time zone issue. But it may well have been a strange coincidence in which my api_key wasn't recognized at first and made it "into the system" right before I retried it with date=, independently of 06:00 or any other special point in time.

BTW I'm glad someone put the extension on the AUR. However in that case the extension is not installed in your home directory, but system wide under /usr/share/gnome-shell/extensions/nasa_apod@elinvention.ovh/. So the last command should be gsettings --schemadir /usr/share/gnome-shell/extensions/nasa_apod@elinvention.ovh/schemas/ list-recursively org.gnome.shell.extensions.nasa-apod.

OK, I see. Yes, the extension is installed globally. This works:

$ gsettings --schemadir /usr/share/gnome-shell/extensions/nasa_apod@elinvention.ovh/schemas/ list-recursively org.gnome.shell.extensions.nasa-apod
org.gnome.shell.extensions.nasa-apod background-options 'scaled'
org.gnome.shell.extensions.nasa-apod pinned-background ''
org.gnome.shell.extensions.nasa-apod set-background true
org.gnome.shell.extensions.nasa-apod screensaver-options 'scaled'
org.gnome.shell.extensions.nasa-apod notify false
org.gnome.shell.extensions.nasa-apod hide false
org.gnome.shell.extensions.nasa-apod transient true
org.gnome.shell.extensions.nasa-apod download-folder '/home/andrej/Downloads/Wallpapers/'
org.gnome.shell.extensions.nasa-apod last-refresh uint64 1602562199178
org.gnome.shell.extensions.nasa-apod api-keys ['[[CENSORED]]']
org.gnome.shell.extensions.nasa-apod last-json '{"copyright":"Cem \\u00d6zkeser","date":"2020-10-13","explanation":"Three very different -- and very famous -- objects were all captured in a single frame last month. On the upper left is the bright blue Pleiades, perhaps the most famous cluster of stars on the night sky.  The Pleiades (M45) is about 450 light years away and easily found a few degrees from Orion.  On the upper right is the expansive Andromeda Galaxy, perhaps the most famous galaxy -- external to our own -- on the night sky.  Andromeda (M31) is one of few objects visible to the unaided eye where you can see light that is millions of years old.  In the middle is bright red Mars, perhaps the most famous planet on the night sky. Today Mars is at opposition, meaning that it is opposite the Sun, with the result that it is visible all night long.  In the foreground is an ancient tomb in the Phygrian Valley in Turkey.  The tomb, featuring two stone lions, is an impressive remnant of a powerful civilization that lived thousands of years ago.  Mars, currently near its brightest, can be easily found toward the east just after sunset.","hdurl":"https://apod.nasa.gov/apod/image/2010/MarsTriangle_Ozkeser_3516.jpg","media_type":"image","service_version":"v1","title":"Mars, Pleiades, and Andromeda over Stone Lions","url":"https://apod.nasa.gov/apod/image/2010/MarsTriangle_Ozkeser_960.jpg"}\n'
org.gnome.shell.extensions.nasa-apod set-lock-screen true

Anyhow, if there's no date in the requests, then this must have been just a coincidence with my api_key taking long to become valid, i.e., not a bug.

Unless a date from HTTP request fields (e.g. Date, .*-Since, Accept-Datetime) is used by the server in absence of the date= GET parameter. (But that sounds unlikely.)

[Elinvention]

I already received a similar bug report in #34. People get a 404 error and then it starts working. I guess I need a way to further debug this. Did the API return a JSON document with the 404 error?

[andrejpodzimek]

Yes, it returned the piece of JSON already mentioned above.

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

(For the record, I actually didn't double-check whether this was really HTTP error 404.)

The key point is that it explicitly mentions a date from the future, because it was past midnight in my time zone, but still 2020-10-12 wherever NASA could possibly reside. That date didn't come from me, because I didn't specify date=. It could have been taken from the HTTP headers by the server, but would a browser send a date without a time zone? (This was Chromium, no unusual browsers involved.) Maybe NASA's server parses the HTTP headers (in absence of date=) and chooses to ignore the time zone in HTTP's Date? (In which case always setting date= to GMT-5 or the like would help, as a crutch to circumvent the issue.)

One way to find out: I'll retry this today/tomorrow after midnight.

[andrejpodzimek]

So my hypothesis had been wrong. It works for me after midnight just fine. If there was a transient issue after I registered the key, it's gone now.