equinor / flotilla

Flotilla is the main point of access for operators to interact with multiple robots in a facility.
Eclipse Public License 2.0
16 stars 38 forks source link

Time used is not correct during the mission #1442

Closed anetteu closed 5 months ago

anetteu commented 8 months ago

Describe the bug During a mission, time used is not correct for all missions. Typically, it shows 60-80 minutes instead of 0-20 minutes. I have not confirmed it, but suspect that there might be an hour offset. The time used is shown correctly for the mission in the history page.

To Reproduce Steps to reproduce the behavior: Start a mission and monitor the time used on the mission page during the mission.

Expected behavior The time used should be correct.

Screenshots If applicable, add screenshots to help explain your problem.

Eddasol commented 8 months ago

Suspect difference in time zone for missions received through API call and missions received through signal R

This PR ensures local time for variables fetched through API call. Might be useful to understand the issue https://github.com/equinor/flotilla/pull/1330

tsundvoll commented 8 months ago

@aestene , do you have some input on the way to solve this?

andchiind commented 8 months ago

The issue seems to be related to this: https://stackoverflow.com/questions/40205893/datetime-kind-set-to-unspecified-not-utc-upon-loading-from-database When we start a mission, the datetime "kind" value is set to UTC, which is received at the frontend with the "Z" flag at the end. When we read the mission in from the database however, the "kind" is not set, causing it to be sent to the frontend without the flag.

andchiind commented 8 months ago

See https://github.com/equinor/flotilla/pull/1476

tsundvoll commented 6 months ago

If this is not formalized somewhere, I think we should always store a datetime as UTC, and only when we display it in the frontend will we change it to local time. Any thoughts on this strategy, @andchiind and @Eddasol

Eddasol commented 5 months ago

Should be fixed by #1553