Platform (Android, iOS, Website): Android App to website communication error?
Of note first, this is not an error I am personally having, but have noticed many times while reviewing observations (I really just review Ontario if that makes a difference.). I’ve noticed a large number of observations being stuck at Casual grade due to missing observation dates, which I leave a comment on in hopes the observer can update it. Sometimes it is a quick fix. Other times the observer responds back that when they look at their observation, the date is shown perfectly fine. This is then understandably frustrating to them when it is multiple observations.
One such example. https://inaturalist.ca/observations/42109851
When I used the .json view (as suggested in a now closed bug report), the date observed data read [“observed_on_string”:null]. I can’t really do anything with that information, but hopefully some of the programmers might know.
I don’t think there’s a way to directly query for observations missing only a date, but I have a workaround that seems to be functional.
Since verifiable observations have a date, a location, media, and aren’t captive, we just have to flip all the switches to get observations missing only a date.
So this asks for observations that are somehow failing the verifiable check, but they’re not failing it due to a lack of photos, being captive, or missing a location – i.e. they must be missing a date.
Note this leaves out sound observations missing a date. Also note observations of Homo sapiens come up in this search, so you might want &without_taxon_id=43584.
There’s currently no way to search for observations that are missing a date. Do you have any reason to believe these missing dates are due to a bug in iNat? I suspect this is just due to people importing photos that have no usable date metadata, and people aren’t choosing one. If you look at https://inaturalist.ca/photos/66840545, you’ll see that we registered no metadata.
Honestly, I’m not sure. Perhaps it’s an issue where the user hasn’t allowed certain settings in the app? It seems to be recording their location just fine. And I don’t know if they are taking their photos directly with the inat app, or from their camera app and then importing. But I’ve had multiple people tell me that when they look at these observations in their app, they can see both the submitted and observed dates.
Edit: At least with this observation https://inaturalist.ca/observations/41185509 (which has since been updated using the desktop platform), the user took the photo with their camera app, then uploaded to the inat app. They were able to see both the submitted and observed dates in the app, but this wasn’t reflected in the view shown on the desktop. Sorry, I should have taken a screenshot, but it was like the other post where it said “Observation date: Not recorded”
It would be best to know exactly how they’re creating observations, including screenshots of what the app/web uploader looks like before the observations are submitted, and what they’re seeing now.
After spending some time talking with users, I’m getting a theory. I think maybe this piece of data isn’t updating with the rest after users enter a new observation on the app. For instance, this experienced user’s observation showed an observation for him on the app, where he entered his observation https://www.inaturalist.org/observations/41998510#activity_comment_4393456. I saw no observation date. Later, the date showed up. I suspect the date isn’t showing up on the website until later, maybe until after another refresh of the app? Is that possible?
And another here, in which the experienced user notes that this happens sometimes when the signal isn’t good out in the field. The date showed up for him in the app until he went to edit it…
So I imagine the date didn’t make it to the iNat servers, not sure why.
What we’ll need are screenshots of what the user sees on their end, detailed steps for replication, and log files from the Android app, but we’d need a very recently uploaded observation for log files.
i wonder if part of the perceived problem has to do with time zones mixed with rules that may disallow observed time > submitted time?
for example:
note in this observation, the observed time > submitted time, which should generally be disallowed, i think. when i go in and try to create an observation with observed time > current time, the app won’t let me. i can select the time and click the save button, but it just won’t take. no error messages pop up letting me know there’s a problem.
i wonder if there’s the also potential that some people may not be syncing their updates?
i don’t think this is a spotty connection issue exactly / per se. compare this observation with the subsequent couple of observations made by this same user, also in the same area. notice that the subsequent observations are recorded just fine and are based on EDT (which i assume is the user’s default time zone, even though the location itself is in California). but notice how the problem observation has a strange observation date (and also photo date) that shows just a date. also notice how that observation stores its submit date as UTC.
i’m just speculating here, but i can see a situation where the user opens up the app and maybe if that first observation is made while the app is still initializing stuff, you can get this kind of weirdness. it seems like it might not know what time zone to use and so that might cause problems somehow.
if you look at
in this case, the observed date is missing, the photo date is missing, but the photo metadata does show a datetime. it’s weird that photo seems to not have translated the photo metadata properly for whatever reason. note the times recorded in this observation and the subsequent observation. they appear to have been observed about 15 minutes apart in roughly the same place. the first observation would have been the first of the day. the time recorded in the photo metadata is very close to the submitted time of that problem observation. so i’m guessing again here, but it’s possible that the app might not be done initializing stuff, and that might be causing problems somehow.
so, so far, it looks to me like there might possibly be 4 kinds of situations mixed up in this thread:
problems while the app is still initializing (noted above in this post)
problems with the metadata in the loaded photo (as noted by kueda, and also present in a couple of other examples noted in the thread. the seem to be cropped photos.)
problems with observed time > submitted time (noted by me in an earlier post)
@peakytea – maybe you’re only noting all these cases for your own reference, but i would guess that your reports would be more actionable if you noted some of the things asked for in an earlier post:
@peakytea We all see the missing dates on the website so no need to post screenshots of it. Screenshot of the app where the “date observed” is shown could be helpful.
