@tiwane – no problem. i was actually going to do one more thing tomorrow. i wanted to add annotations or IDs to my test observations to see if that triggered the system to update the observed date to a different date.
1 Like
ok… I was able to reproduce the "3 septiembre " problem (described above) in one of my observations here: https://www.inaturalist.org/observations/19386749. I set this up yesterday, and the Observed date was set by the system as 5/21/2019 3PM, but when I made a change to the Date is Accurate flag this morning, the system changed the Observed date to 5/22/2019 3PM.
I guess technically, there is a data problem at the bottom of at least these kinds of observations. So I wonder if the right thing is to set the Date is Accurate flag = N in these cases?
The system should probably warn that it doesn’t know how to interpret the string accurately, though, and it probably shouldn’t keep changing the dates upon updates. Definitely in these cases where it seems to not be able to parse any part of the string, it should warn the user. In the susanhewitt-type cases, it seems to be able to parse day and month but fills in a year, the system should probably still warn.
1 Like
It is odd behaviour. I would think it shouldn’t be trying to change the date field unless the user is entering a data change. Definitely a bug.
2 Likes
This happened today, it looks like the user was somehow able to add a date one day after the date submitted: https://www.inaturalist.org/observations/14923965
Should I tell him or should I wait so you can take a look at it first?
1 Like
That one definitely looks like observer made the change :)
I’m guessing there is a check to make sure the date is not in future relative to the change, but maybe it should be relative to the submission date? Are there situations where an observer might legitimately create an observation BEFORE they actually observed it? I just can’t see myself thinking “today I will go out and photograph a Woillemia, and I will create the observation now so that it is ready for the photo to be added later”.
2 Likes
@tiwane – i noticed that you’ve logged this in GitHub as an improvement. i wonder if it really should be classified as a bug, since in some of these cases, the system is actually coming in and setting these dates/times in unexpected ways?
It looks like there was a validation added to prevent the “observed on” date from being saved if it is greater than the “created on” date. I haven’t fully digested what else was discussed here. Did that resolve the issue (at least going into the future, since it doesn’t fix the existing observations)?
yes, it does look like this prevents new occurrences of the “3 septiembre” problem and the “susanhewitt” problem. it doesn’t seem to change the behavior of the system when it encounters a date it’s not able to parse properly. so it’s not always obvious that you put in a date the system doesn’t know how to handle.
the fix here probably also prevents the workflow where someone creates a blank observation and then edits it later to capture something observed after the create date. but i don’t think i’ve seen many complaints about that since this has been implemented. so maybe that’s ok.