(There’s also a time picker icon, but it’s not prominent and is easily missed, I think. I didn’t see it for years…).
Click on a date, and iNat enters the date and the current time and time zone into the field, formatted in a pretty nerdy way:
Most of the collection projects I look at come from people writing to help@inaturalist.org so my sample is probably pretty biased, but almost every one I see that has a date range shows dates plus weird start and end times that were clearly the ones automatically entered when the project creators chose a date and unnoticed or disregarded.
I’m curious if others see this as a widespread problem, and if you have ideas on how the user interface could be improved here. I’m thinking having clearly defined fields for date, time, and time zone would be cool, but one could also imagine that after the date has been chosen, we just show you the time picker instead of filling it all in automatically.
hmmm… this is tricky because the observation date is not always captured in a particular format. i think it can be captured with just a date without time, a date and time with offset, or a date and time with time zone.
with that in mind:
i think if you filter by just dates in the range, you’ll pick up anything that falls within that date at the observation’s recorded time zone (offset).
but if you filter for, say 2021-01-01 08:00 -06:00 to 2021-12-31 21:59 -06:00, i think that would potentially exclude some observations:
a. i think times in the web are rounded to the minute (recorded without seconds), but times in the apps have seconds. so something recorded on 2021-12-31 21:59:50 -06:00 might be excluded.
b. if an observer has the wrong time zone or offset set up, i think something like 2021-12-31 21:59 -07:00 would be excluded
c. if an observation is recorded at 2021-01-01 with no time, i suspect that it could get excluded
if there’s more time-based obscuring changes in the future, i suspect the obscured times would operate as if no time recorded
and then can you filter for 2021-01-01 08:00 (no offset) to 2021-12-31 21:59 (no offset) for that range? what happens in that case? does if filter for 2021-01-01 08:00 to 2021-12-31 21:59 at the observation’s local time zone, or does it filter as if 2021-01-01 08:00 +00:00 to 2021-12-31 21:59 +00:00?
i suspect the typical use case for a date/time-limited project will be to limit based on date only. so i think it would make sense for a date picker to return just a date without a time and offset by default (#1 above).
but i guess you do need to have mechanism for the user to also select/input a time and offset. i think it would be most clear if for a given date/time you had separate input boxes for date, time, and offset, plus a separate date/time picker button. (i think you would want a single date picker that interacts with all 3 input boxes because offset is determined only in the context of both date and time.) having a single input box for date+time+offset might be okay, if your date picker would not add a time+offset to the input if you did not actually select a time.
i think the other thing that might be useful is to have time selector default to 00:00:00 for the d1 “range from” parameter and to 23:59:59 (note the extra :59) for the d2 “range to” parameter. but i’m not certain how the offset should be defaulted (since i’m not sure how #3 above operates).
