Large number of app users with Date Observed missing

Bug Reports
28

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 https://forum.inaturalist.org/t/account-time-zone-sometimes-automatically-sets-itself-to-hawaiian-time/11940)
  2. unresolved issues from or similar to https://forum.inaturalist.org/t/some-observations-not-showing-time-in-the-timestamp/1250
  3. and the rule that requires observed date <= current date, related to https://forum.inaturalist.org/t/date-submitted-before-date-observed/3120

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 https://forum.inaturalist.org/t/account-time-zone-sometimes-automatically-sets-itself-to-hawaiian-time/11940).

consider that HST is -10:00 vs UTC/GMT, and then compare her observations that are casual vs not: https://www.inaturalist.org/observations?place_id=any&subview=table&user_id=sarahkristine&verifiable=any. 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 https://forum.inaturalist.org/t/some-observations-not-showing-time-in-the-timestamp/1250). it looks like there are exceptions when the time falls between 12PM and 1PM HST (similar to https://forum.inaturalist.org/t/some-observations-not-showing-time-in-the-timestamp/1250/11).

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 https://forum.inaturalist.org/t/automatic-time-zones/7760) when loading.

for https://www.inaturalist.org/observations/50990967 (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 https://www.inaturalist.org/observations/50476431 (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 https://forum.inaturalist.org/t/date-submitted-before-date-observed/3120). 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…

2 Likes