Fix timestamp issues in V2 UI modals

[scottveirs]

Problem:

Comparing the V1 to V2 view of an SRKW sighting that came in around 13:00 (GMT-800) on 20 Nov 24--

and then examining the created and ssemmi_date_added fields for that sighting in the API response to GETTING the recent sightings --

{"ssemmi_id":"SPOTTER 213564",
"data_source_name":"Spotter-API",
"data_source_entity":"Conserve.io",
"data_source_id":213564,
"created":"2024-11-20 20:50:00",
"photo_url":"",
"no_sighted":6,
"latitude":47.59644,
"longitude":-122.47228,
"type":"Orca",
"data_source_witness":"cascadiaWebMap",
"trusted":1,
"data_source_comments":"[Orca Network] 5-8 orcas southbound (Amy Fowler)",
"profile":{"name":"spotter"},
"entry_id":"d89bb673-23f0-44d0-ad4b-c63bf7db692e",
"ssemmi_date_added":"Wed Nov 20 2024 21:02:40 GMT+0000 (Coordinated Universal Time)",
"submitter_did":"did:ethr:0x20fd1096eaafb242a88272e20d7a77b552fa6cd8",
"signature":{"r":"f202631b1c740c9fa963a256ace48862063c71be81a0fc5bbc92f6f31c88ab8e",
                      "s":"300e6a5f5666dd9891e080e8b64ef76cb95e40166a7675667a50f4d086f4fba0"}}

I have some suggestions and identify two likely bugs and a typo:

1) Rather than Time of sighting I prefer the less specific Time of observation or more briefly Observation time -- mainly because Acartia aggregates acoustic occurrences ("hearings") in addition to visual observations ("sightings"). Plus there are likley other types of occurrence observations coming, e.g. thermal camera and radar detections...

2) The modal should display the "created":"2024-11-20 20:50:00" value at the top since that is the time the observation of Nature was made. Instead, it seems the modal is displaying the "ssemmi_date_added":"Wed Nov 20 2024 21:02:40 GMT+0000 (Coordinated Universal Time)" value -- which is fine to display, but is of secondary importance. (If there aren't other strong opinions from the UX/design team, @robert-ohurley, I'd recommend putting the created datetime near/at the top as an Observation time: and the ssemmi_date_added datetime near the bottom as a Date added: value.

3) Rather than (PT), the ideal way to indicate that a timestamp is local would be to either type (PDT/PST) or better yet (GMT -800) or (GMT-700) depending on whether Seattle is under daylight-savings time or not, seasonally.

4) The time conversion to local time seems to be off by 4 hours? (In this example the modal phrase Time of Sighting (GMT): 2024-11-20 21:02:40 was accurate and optimal (except I'd prefer Observation time (GMT)), but the modal phrase Time of Sighting (PT): Thu, 21 Nov 2024 09:02:40 should have displayed the local time 13:02:40 instead of 09:02:40.

Proposed solution

[robert-ohurley]

Okay, to summarise, is this correct?

1. Time of sighting renamed to Observation time
2. Observation time reflecting the created field (positioned at the top).
3. Date added reflecting the ssemmi_date_added field (positioned at the bottom).
4. Indicate that a timestamp is local with (PDT/PST)
5. Additionally, in adding Observation time (GMT) to the popup, would this just be the created field + a 8 hour offset?

[scottveirs]

@robert-ohurley 1-3 are correct

Re 4-5 -- my understanding is that all datetime stamps in Acartia are stored in UTC. Do you concur @aalaydrus ?

If so, then it would be ideal to change your summarization of 4 and 5 thusly:

4. To display the local time (per number 2), first use a Python library like pytz to convert from UTC to the Pacific time zone. This is better than just subtracting 8, because part of the year in the Pacific time zone in Seattle you should instead subtract 7... Having allowed the library to figure out when you should account for daylight savings or not, display the resulting local datetime stamp with the relevant zone annotation. You could use PDT or PST as you suggested, but I'd also be happy with you appending GMT-0800 or GMT-0700.

5. Yes, but you should be able to just write the datetime from the database without conversion, and then clarify it is in GMT or append a Z