Large number of app users with Date Observed missing

Ummm…I was not posting for my own reference, but because I thought there was some interest in on the part of the IT group to follow up with users. I’m sorry, but I don’t have the time or expertise to do so. If there’s nobody with the bandwidth and expertise to do that, then this is the last I’ll post. I certainly can’t collect screenshots from another user’s account!

This user tried to fix the date, but was unable to do so.

Goodbye and good luck with this.

1 Like

not sure if this helps with the problem(s) in this thread, but i noticed something while trying to reproduce the problems here, and i didn’t expect it. so i wanted to note it here, just in case it is not a known thing.

earlier i noted that some of the photos that seemed to be coming in with no metadata seemed to be cropped photos:

so i wanted to see if cropping / editing the photos was somehow stripping the metadata. (i was using the stock Google Photos app on my Pixel 3a to edit photos.) long story short, i realized that if i use the iNaturalist app to take a photo, the resulting photo is different from the photos i take in my stock Google Camera app. the iNat app photos are named something like “20200428_1855517661492482631352002”, while the stock app photos are named something like “IMG_20200427_142334”. but more significantly, when i copy the photos onto my Windows machine to look at the photo metadata, i notice that the iNat app photos have only a Date Created and Date Modified, while the stock app photos have a full set of metadata captured, including a Date Taken. i wasn’t expecting a difference in the metadata stored by photos taken in the iNat app.

it seems like when the Date Taken is missing, the iNat app may be using the Date Modified as a proxy for Date Taken. this is problematic because when i crop and save a copy of a photo taken in the iNat app, it’s the date that i made the edited copy that seems to be getting loaded as the Observed Date, not the actual date the photo was taken. (oddly, Google seems to know when the edited copy was taken because i can see it in the photo details in the Photos app, but it doesn’t seem to share that information, such as when i copy the photo to Windows and view the photo attributes.) for comparison, if i load an edited copy of a stock camera app photo, the resulting observation will show an Observed Date matching the date the photo was taken…

that’s as far as i’ve gotten with this at this point, and i’m not sure if it’ll actually lead anywhere relevant to this topic…

i thought maybe if changed the date / time on my phone when editing the iNat app photo, that somehow that might affect what gets loaded. when i shifted my phone’s system date a day forward, the resulting edited copy of the photo reflected a Date Modified that was a day ahead, and when i tried to load an observation using that photo, it simply would not load/sync. (the iNat app didn’t give me any errors though.) if i moved the system date a few hours forward but still on the same date, the resulting edited copy would load okay and reflect the future time. i thought maybe if i first loaded a blank observation and then later tried to load a future dated photo, that maybe that could confuse things, but actually in that case, the app does throw up an error message letting me know that i’m not allowed to submit an observation with an observation date after the submit date…

@peakaytea – i hope you’ll still participate in the forum and on iNaturalist even if you choose not to post further to this thread. i do appreciate your effort in trying to chase this down, and i think others do, too. if in the future you do notice a very recently uploaded observation that is missing observed date and feel so inclined, you could try asking the user to send a screenshot of what they see (and maybe even a log file) to the iNat staff (


Sure, I’m not going anywhere. I just don’t know how I can be useful in nailing down this problem, or if it’s a priority.

I’m sorry if I wasn’t clear earlier, but please refer any of these users to so we can discuss with them what information we’ll need to track this down. We really need screenshots of their upload process, log files, etc.

I cannot retry it cause I have thrown away the photos but my experience is then when you retry a few times the location data and the date data are correctly imported into the Android app.

I use the symbol in the circle right below. ( Only look at this circle) .

OK I have an interesting one here. My friend in Newfoundland (not too far from Ontario) is having some variation of this issue.

She has about 19 casual grade observations due to the date being blank in the app, even though it is present in the JSON via “observed_on_string”.

All of the observations made in 2020 in this list:

Here is an example:

If you look at the JSON there is an accurate “observed_on_string” and the time zone is wrong in the “time_zone” and “zic_time_zone” fields:

Her images have Newfoundland Daylight Time in the “observed_on_string”: GMT-0230 (GMT-2:30)

But the “time_zone” and “zic_time_zone” say a “Hawaii” / “Pacific/Honolulu”

The location data on the observations is accurate.

1 Like

i think these are probably different than the cases from the original post, but they are still interesting. i suspect that these cases are related to:

  1. bad time zone set up (see
  2. unresolved issues from or similar to
  3. and the rule that requires observed date <= current date, related to

if either 1 or 2 above were resolved, i think that would prevent the problem from occurring. so the quickest / easiest thing for that specific user to do would be to fix her time zone, i think.

more details:

it looks like most, if not all, of her observations are made on the iPhone app. it looks like her time zone is probably incorrectly set to Hawaiian time (see

consider that HST is -10:00 vs UTC/GMT, and then compare her observations that are casual vs not: it looks to me like observations that are created at 10AM HST or later are generally casual, while most created prior to 10AM HST are generally ok (though time still doesn’t show up on most of the observation dates, similar to it looks like there are exceptions when the time falls between 12PM and 1PM HST (similar to

so then let’s work through a couple of these examples to see what might be happening in more detail. note that regardless of what time zone / offset is recorded by the camera, the system will assume the time zone in the user profile (see when loading.

for (research grade), you have:

  1. iNat determined (current) date: “created_at”: “2020-06-26T05:05:33-10:00”,
  2. camera timestamp: “observed_on_string”: “Thu Jun 25 2020 19:19:23 GMT-0230 (GMT-2:30)”,
  3. camera date converted by iNat to HST: “observed_on”: “2020-06-25”,

think specifically of the conversion of #2 to #3. since iNat simply ignores the camera’s time zone/offset in favor of the time zone in the user profile, it’s assuming 6/25 19:19 HST as the date observed. note that if you convert that to UTC (add 10 hours), you get 6/26 5:19 AM UTC. (then if you ignore the time zone offset in #1 and compare, you get the same day but a later time.)

for (casual), you have:

  1. iNat determined (current) date: “created_at”: “2020-06-21T11:46:27-10:00”,
  2. camera timestamp: “observed_on_string”: “Sun Jun 21 2020 16:04:42 GMT-0230 (GMT-2:30)”,
  3. camera date converted by iNat to HST: “observed_on”: null,

again thinking of the conversion of #2 to #3, iNat would have assumed a date of 6/21 16:04 HST, which converted to UTC is 6/22 6:04 AM. (if you ignore the time zone offset in #1 and compare, you get a later day.)

there’s a rule that is supposed to make sure the observed date doesn’t happen after the submit date (see so i bet some sort of weird comparison like what i did above is occurring, causing the system to think that the rule has been violated, and leading it to drop the date in those instances…


Thanks for the detailed and informative response. I will share with the user. Is the best way to fix her observations to resubmit them or will she be able to re-sync with her images after correcting her timezone?

i think if i had this issue, i would correct the time zone, compile a list of problem observations with the expected dates (see below) and then use bulk edit (have her click edit on this page:✓&quality_grade=casual) to fix the existing observations without dates. (instead of bulk edit, she could also try to correct the observations one by one, since there are just under 20.)

here’s a list of the missing dates:

location taxon name obs id missing date
Bowring Park, St. John’s, NL, CA Agrocybe 50476431 Sun Jun 21 2020 16:04:42 GMT-0230 (GMT-2:30)
Bowring Park, St. John’s, NL, CA Leptophlebiidae 50476368 Sun Jun 21 2020 16:38:27 GMT-0230 (GMT-2:30)
Bowring Park, St. John’s, NL, CA Myosotis scorpioides 50476166 Sun Jun 21 2020 17:11:36 GMT-0230 (GMT-2:30)
Bowring Park, St. John’s, NL, CA Arianta arbustorum 50476111 Sun Jun 21 2020 17:19:37 GMT-0230 (GMT-2:30)
Bowring Park, St. John’s, NL, CA Bonasa umbellus 50476010 Sun Jun 21 2020 17:56:32 GMT-0230 (GMT-2:30)
Pippy Park, St. John’s, NL, CA Rickenella fibula 48702249 Sat Jun 06 2020 17:12:46 GMT-0230 (GMT-2:30)
Newfoundland, St. John’s, NL, CA Apiosporina morbosa 48701394 Sat Jun 06 2020 17:29:32 GMT-0230 (GMT-2:30)
Pippy Park, St. John’s, NL, CA Sphagnum 48700987 Sat Jun 06 2020 16:25:34 GMT-0230 (GMT-2:30)
Pippy Park, St. John’s, NL, CA Coptis trifolia 48700827 Sat Jun 06 2020 16:19:17 GMT-0230 (GMT-2:30)
Pippy Park, St. John’s, NL, CA Cornus canadensis 48700447 Sat Jun 06 2020 16:14:24 GMT-0230 (GMT-2:30)
Left Pond, St. John’s, NL, CA Lonicera villosa 48700261 Sat Jun 06 2020 16:13:46 GMT-0230 (GMT-2:30)
Pippy Park, St. John’s, NL, CA Polytrichum juniperinum 48700157 Sat Jun 06 2020 16:04:24 GMT-0230 (GMT-2:30)
Pippy Park, St. John’s, NL, CA Cypripedium acaule 48700057 Sat Jun 06 2020 15:53:49 GMT-0230 (GMT-2:30)
Pippy Park, St. John’s, NL, CA Nolanea 48700004 Sat Jun 06 2020 16:14:49 GMT-0230 (GMT-2:30)
Newfoundland, St. John’s, NL, CA Clintonia borealis 48699760 Sat Jun 06 2020 15:44:45 GMT-0230 (GMT-2:30)
Newfoundland, Torbay, NL, CA Cardamine pratensis 48399391 Wed Jun 03 2020 18:36:23 GMT-0230 (GMT-2:30)
Newfoundland, Flatrock, NL, CA Alnus 47770001 Fri May 29 2020 17:05:26 GMT-0230 (GMT-2:30)
Newfoundland, Flatrock, NL, CA 47769933 Fri May 29 2020 16:45:10 GMT-0230 (GMT-2:30)
Newfoundland, Torbay, NL, CA Aphodius 47127809 Sun May 24 2020 13:13:34 GMT-0230 (GMT-2:30)
1 Like

Problem solved by updating time zone. Thank you!

I have a question about this behavior:

Should users switch the time zone under their account settings when traveling or uploading observations from a trip to a different time zone?

1 Like

I know I upload from IOS photos and it is often missing date and location, which then I input manually, using the data shown on my iPhone Photos app.

i think it depends on whether you’ve changed the time on your device. if, say, your camera still reflects your home time zone, then i would upload those photos using your home time zone. but if, say, your phone automatically changed its time zone to your destination time zone, then i would change time zone in iNaturalist before loading those photos.

you can also look at this thread that i referenced earlier: it contemplates a system change to address the need to change time zones in your profile settings, but no changes to the system have been made at this point.


I use the share button in the Google Photos app all the time and have never seen a missing date. Missing locations can happen when the photo you’re sharing isn’t actually stored on your device and must be downloaded from Google before sharing with the iNat app on your phone. For some reason Google Photos doesn’t share location metadata in that situation, and you have to download the file to your device before sharing for iNat to get the coordinates. However, I’ve never seen that issue affecting dates before.

@kueda did you rule out the possibility of the “Adelaide issue” in the case from arvel? Newfoundland also has a 30 min offset.

Hadn’t thought of that and it might be affecting people in Newfoundland, but the obs cited in the original post don’t seem to be from Newfoundland or by people with a Newfoundland timezone.