You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Doing the WESL training there are questions like "What rangers responded to an SV incident at 04:30@D on 7/31@20:50". I'm using the IMS training server from Mountain Daylight Time (America/Denver), and that incident shows in the UI at 21:50.
On the assumption that all IMS incidents happen in Black Rock City, I'm of the opinion that times should always be displayed in Pacific Daylight Time, not whatever time zone the user's browser happens to think it's in.
Besides the training use case, this could be relevant if we continue the remote-operator setup that (I think) we used some in 2022. If someone's operating from Sydney, both computer-generated and free-text dates and times should use the same Nevada time reference, and not mix in New South Wales times.
The text was updated successfully, but these errors were encountered:
OK this is reporting behavior in the web client built into the server, not this one, but we'll keep this to verify that the problem doesn't carry forward.
I'm pretty sure it does, because the browser should be displaying date-times in the local time zone of the user…
I agree with @flwyd that it'd be sensible and less confusing to only show America/Los_Angeles times in the web clients. In the backend, maybe an Event could be associated with a tz string, and that would be fed to the web clients to help them render datetimes?
Doing the WESL training there are questions like "What rangers responded to an SV incident at 04:30@D on 7/31@20:50". I'm using the IMS training server from Mountain Daylight Time (America/Denver), and that incident shows in the UI at 21:50.
On the assumption that all IMS incidents happen in Black Rock City, I'm of the opinion that times should always be displayed in Pacific Daylight Time, not whatever time zone the user's browser happens to think it's in.
Besides the training use case, this could be relevant if we continue the remote-operator setup that (I think) we used some in 2022. If someone's operating from Sydney, both computer-generated and free-text dates and times should use the same Nevada time reference, and not mix in New South Wales times.
The text was updated successfully, but these errors were encountered: