Replies: 2 comments 1 reply
-
@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. |
Beta Was this translation helpful? Give feedback.
-
Hmmm but for the connector (using the |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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 inEg: 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 theendtime
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 ?
Beta Was this translation helpful? Give feedback.
All reactions