Times handled inconsistently across Python API, Connectors and Server

[wk9874]

Hey all, I've noticed that the timestamps which are reported by Simvue for the start / end times for a run are handled inconsistently between different components of Simvue. For example:

Python API
Inside the Python API, the start time is registered as a time.time() object, without a specific timezone applied. This means a different number will be reported depending on the timezone which the user is performing the simulation in
Eg: https://github.com/simvue-io/python-api/blob/8f13a7adb2ad0ec53f0a4949e44e1c5676ae342d/simvue/run.py#L548

Some parts of the Python API also use UTC time:
Eg: https://github.com/simvue-io/python-api/blob/8f13a7adb2ad0ec53f0a4949e44e1c5676ae342d/simvue/utilities.py#L394C1-L395C1

And when providing metrics / events, a timestamp is accepted in a string format (which I guess we don't really have control over since the user sets that)

Connectors
Inside some of the connectors, there is a 'load' functionality which can upload historic runs to Simvue. These parse timestamps from output files to set the started and ended times, as well as timestamps for metrics/events. To do this we take the string from the output file, load it in as a timestamp (not using a timezone, so local time), and then either reformat this as the correct string for upload with metrics/events or send the raw timestamp number to the server for started/ended times.
Eg: https://github.com/simvue-io/connectors-fds/blob/8d66bb9e2bdd1e0a52726c47d1ff9d610fc84b1a/simvue_fds/connector.py#L131

Server
If the timestamps for metrics/events, or the starrted & ended times, are not specified by the user via the python API, the server will create timestamps using UTC.

UI
The UI converts timestamps to a date, but does not factor in which timezone the user is in.

Impact
These inconsistencies mean that the times reported by the web UI to the user are unreliable. Eg here is a run where I the FDS Connector (using load) automatically set the endtime to be the timestamp of the time the input file was last modified (which was immediately before the run was started - 14:45 BST). Because the Connector uses local time (BST), and the server uses UTC, the UI claims that the run took an hour, when it really took about a second.

We need to decide how to handle this - probably make it consistent across the Python API, Connectors and Server that we measure time in UTC, and then get the UI to convert that timestamp to the relevant timezone for where the user is connecting from?

Thoughts @alahiff @kzscisoft ?

[kzscisoft]

@wk9874 Yes the time should be consistently UTC throughout, as the user should be ultimately able to specify a timezone on the UI and the run data just be read as that timezone.

[wk9874]

Hmmm but for the connector (using the load functionality for historic runs), 'measure in UTC' wont really work... If say you run a simulation while in a BST timezone, FDS will report the time which you ran it in local time, so eg 14:45 (without telling you the timezone). We load that in as a UTC time and then send it to the web UI, where it will detect that I am in BST, and so will +1 to the time. So will it show me 15:45 in the web UI? :/

[kzscisoft]

This sounds like the connector itself would need to ensure upload is UTC not BST