Problem
Time filtering on GMT timestamps may be confusing or non-optimal for local users.
Context
Testing the filtering capabilities this morning, I noticed that the current time filtering seems to be based on the GMT time stamp of an observation. For a professional/academic scientific audience this is appropriate, but for many use cases the local time will likely be more useful.
For example if you are a community scientist trying to participate in a local sighting network by matching your photos to the track of a particular marine animal, the photos will have a local time stamp. Since they were all taken during the daylight hours of the local day, it would be confusing to only see the portion of the days track for the imaged animal and possibly points of it the day before or after.
Example with screenshots
Southern resident killer whale observations filtered for 24 Nov 2024:

Southern resident killer whale observations filtered for 23-24 Nov 2024:

Note in the 2nd screenshot that the local Time of sighting has a date of 24 Nov 2024 so if the local datetime stamp were being used for filtering, this point would have been shown in the first screenshot. It wasn't, so this confirms that the UTC timestamp is currently being used for time-filtering.
Proposed solution:
Change to time-filtering based on the local time stamp (once accurately computed by completing #66).
Bonus idea:
Have a checkbox somewhere near the time filtering UI to allow a professional/academic user to optionally enter datetimes in UTC and have data filtering based on them. The default, though, should be for that box to be un-checked (default to local times for filtering).
Problem
Time filtering on GMT timestamps may be confusing or non-optimal for local users.
Context
Testing the filtering capabilities this morning, I noticed that the current time filtering seems to be based on the GMT time stamp of an observation. For a professional/academic scientific audience this is appropriate, but for many use cases the local time will likely be more useful.
For example if you are a community scientist trying to participate in a local sighting network by matching your photos to the track of a particular marine animal, the photos will have a local time stamp. Since they were all taken during the daylight hours of the local day, it would be confusing to only see the portion of the days track for the imaged animal and possibly points of it the day before or after.
Example with screenshots
Southern resident killer whale observations filtered for 24 Nov 2024:

Southern resident killer whale observations filtered for 23-24 Nov 2024:

Note in the 2nd screenshot that the local
Time of sightinghas a date of 24 Nov 2024 so if the local datetime stamp were being used for filtering, this point would have been shown in the first screenshot. It wasn't, so this confirms that the UTC timestamp is currently being used for time-filtering.Proposed solution:
Change to time-filtering based on the local time stamp (once accurately computed by completing #66).
Bonus idea:
Have a checkbox somewhere near the time filtering UI to allow a professional/academic user to optionally enter datetimes in UTC and have data filtering based on them. The default, though, should be for that box to be un-checked (default to local times for filtering).