Description
I had a conversation with a researcher at CDS who was saying that they often got in a muddle with time zones - they mentioned that being on the west coast made it worse, because sometimes times displayed in UTC, sometimes ET, and sometimes local time. As an east coaster I probably have a blindspot about this!
It would be ideal if all timezones on CHS acted in a predictable way, but we need to think about what that would be! Remember that the participant's local time is very helpful for things like noticing mismatches between expected and actual time (scammer issue)
There are at least 4 time zones in play:
- UTC
- ET (CHS's own 'local' default, likely baked in by various east coast staff members over the years)
- Participant's time zone (at the time of a session)
- Researcher's time zone when viewing the site
Which does the email query system use? Which is recorded by the frameplayer? Probably there are many many chances for this choice to get made, and it's not clear to me that we have a consistent approach.
This is probably lower-priority, but would be a quality of life improvement and probably make debugging, scam tracking, participant management etc. easier in a meaningful way. Probably, it requires a scan through the whole codebase.
As a stopgap, we can at least try and decide on a default posture going forward!
Description
I had a conversation with a researcher at CDS who was saying that they often got in a muddle with time zones - they mentioned that being on the west coast made it worse, because sometimes times displayed in UTC, sometimes ET, and sometimes local time. As an east coaster I probably have a blindspot about this!
It would be ideal if all timezones on CHS acted in a predictable way, but we need to think about what that would be! Remember that the participant's local time is very helpful for things like noticing mismatches between expected and actual time (scammer issue)
There are at least 4 time zones in play:
Which does the email query system use? Which is recorded by the frameplayer? Probably there are many many chances for this choice to get made, and it's not clear to me that we have a consistent approach.
This is probably lower-priority, but would be a quality of life improvement and probably make debugging, scam tracking, participant management etc. easier in a meaningful way. Probably, it requires a scan through the whole codebase.
As a stopgap, we can at least try and decide on a default posture going forward!