Well the observation numbers clearly suggest they were created back in February etc, all appear to have been retospectively edited after creation.
I think there are possible options:
they tried to duplicate something and it did not work
they edited the date to get the records into the CNC, possibly just because they wanted it in the CNC, or they ‘saw’ it again but couldn’t be bothered to create a new record.
Can’t be certain of motive, but it seems pretty suspicious, and there were examples of similar behaviors in other CNC places. We’re discussing a way to prevent situations like this.
I also have a number of similar observations that have been submitted before the observation took place. This happend when i tried to add about 150 observations or so to a project and obviously misunderstood some of the online advice … the result was that about 150 of my observations were copied by the system. As it was sometimes tricky to upload new observations, due to the bad connection i have here, I decided to reuse the meaningless copies and transformed them into something meaningful by adding my current photos and new identifications.
I actually wonder why this should be suspicious … as one date is clearly the date when the database entry was made, while the other date is the date of observation. Which means that how the dates relate to each other, is just a question of workflow and nothing else. With many different users you will get many different styles of workflow.
Just to get a better extent of this phenomenon I used the search filter to find observations with “date added” in 2016 but the “date observed” is in 2018. In other words, these observations were added to iNaturalist over a year before the organism was actually observed in the field.
Susan Hewitt at the top of that list when I looked… pretty sure Susan wouldn’t have fudged a date. I wonder if this is a “wrong date/time on camera” and the image tags are the source of the incorrect date?
i looked at several of these cases, and it does look like the observers manually changed the observation dates, since they don’t match the metadata on the photos. but whether the changes were intentionally misleading is another question. some do look like they may be, some look like they aren’t. in the Susan Hewitt case, the observation date is the same date as the submittal date, just 2 years later. so something like that might just be a fat fingered date correction. seems like this would be relatively easy to prevent, simply by disallowing observation date > submit date, or displaying a message if the date in the photo metadata is significantly different from the manually changed observation date.
this seems to be true if you already have an observation date recorded and change it. but if you delete the date, save it, and then come back and add a date, then the obs date > submit date check doesn’t seem to fire. see what i did to one of my observations: https://www.inaturalist.org/observations/21587563.
EDIT: actually, the check seems to be obs date cannot be greater than current date. so you can come back and change the observation date, as long as it’s not > current date.
What I think that shows is that it is NOT the observer making the change, it is coming from the system. It is likely able to future date because it is not validating the date first. That date is yesterday, so maybe a stray date/time stamp going to the wrong field?
In the example above (https://www.inaturalist.org/observations/4025819) the year has changed from 2018 to 2019 now. Seems the system changes the date automatically to the current year as soon as the day and month of observation has passed (15th of May) :D. A funny bug that keeps observations younger than 1 year :D. Maybe there is something wrong with the pictures date metadata?
it actually seems that the observation date is constantly changing. yesterday when I looked at it, it was observed at May 15, 2019 3PM CDT, and today, it was observed at May 16, 2019 3PM CDT. it comes via naturalista.mx. so I wonder if that has something to do with it? or i suppose it’s possible that the user is using the API interface to update the observation maybe? i wonder if the API gets the same validations as the website?
i think i see what may be going on, at least in some of these cases. looking at what the API returns, it looks like the observed_on_string field on some of these observations is not valid. for example, in the observation 4025819 (see https://api.inaturalist.org/v1/observations?id=4025819), the observed_on_string field = "3 septiembre ", which is invalid (no year, no time). if you look at when it was last updated, updated_at = “2019-05-16T11:07:19-05:00”, and the observed_on field (not the observed_on_string field) = “2019-05-16”. so i think what’s happening is because the observed_on_string field is bad, the system sets the observed_on date to the date of the last update (which i assume means any ID or annotation, etc.), and the time becomes 12AM, adjusted for the time zone.
so if you see an observation with a funny timestamp, and the timestamp has a time that is a whole hour (no minutes, no seconds), and if the timestamp changes if you update the observation, then i bet that’s what’s going on.
for observations that don’t follow this pattern, there’s probably something else going on… maybe the observer is manually changing stuff. for example, in the susanhewitt example (https://api.inaturalist.org/v1/observations?id=4591787), the observation also has a bad observed_on_string value, so maybe she saw that the date was wrong at some point, and she updated it, but updated it to the wrong year?
EDIT: maybe the susanhewitt observation is still a case of the system incorrectly interpreting date/time strings. see my test case below. i wonder if in her “Thu Nov 17 2016, afternoon” string, the system might not be recognizing “2016,” as a valid year and just setting it to the current year at the time of the last update (2018)? UPDATE: yup: i updated this observation (https://www.inaturalist.org/observations/21587563) with susanhewitt’s string, and the system translated that to “Nov 17, 2018 · 8:16 PM CST”, which is similar to her observed date/time, except different time zone.
UPDATE: i went back and checked, and the system does not seem to consider time when doing its observed date > current date filter, but the way the system interprets the time as described below may still be a small problem:
ORIGINAL POST:
i tried to create a test observation with an invalid date/time, and it produced an observed time that is in the future. i created it at 9:43 CDT today (21 May 2019), then edited the observed date to “21 may 2019 afternoon” a few minutes later, and somehow, the system determined that the observed date should be interpreted as “May 21, 2019 · 8:19 PM CDT”.
