I think I might have run into a bug in Emlid Flow 360!
On the 22nd March I created an Emlid Flow project and recorded 5 data points with an RS3. On the same day I exported a project .csv file from Emlid Flow on my tablet. At that point in the calendar, the UK was running on standard GMT/UTC+00:00. This created a file in which the data points showed their Averaging Start and Averaging End times as
Move on in time to April and I used EmlidFlow360 (aka the online version) to re-export a copy of the .csv file. In the UK weāve now switched from GMT (GMT/UTC+00:00) to BST (GMT/UTC+01:00). Only now the times show up as:
The exported time has been advanced by +1hr. (Additionally, for a couple of the timestamps, the decimal 1/10ās of a second change -in the above example from 09:17:57.8 to 10:17:57.7)
If I revert back to exporting the same project .csv file via EmlidFlow on my tablet, then the exported times are correct as originally recorded - ie they arenāt advanced by an hour.
The times show correctly if I click on a point in the web browser, so itās something with the export routine. in the online version of Emlid Flow360.
Iād wager that its likely a programming issue using current date for time zones when the data is exported. In the background, it would all be GMT/UTC+0.
If the times arenāt really all that important for you, I doubt there would be no concern, however it might get interesting if post processing were done in Studio perhaps. Maybe Emlid can confirm?
The times you highlighted are referring to the same moment of time. It shows UTC+1 as there was indeed a 1-hour move on time in your location. In general, it shouldnāt affect the accuracy of your data in any way.
Itās only because of rounding algorithms. It shouldnāt affect the quality of your survey, either.
Good question, @joelbladen! Emlid Studio uses GPS time for its calculation. In terms of time, it only requires that the files that you use overlap.
Apologies, Iām working across so many bits of software , each giving so many different times; configurations and bugs that itās getting very confusing!
It might be an idea to have Emlid Flow and Flow 360 export the timestamps in the same way/format, that way someone like me doesnāt unwittingly get confused and read them as being different times
The time exporting relies on the time zone settings on your device. However, I agree with Bryan that working with UTC can be quite a convenient option.
Would you like to use these exported times for some further applications? If so, can you please share more details about it?
The ābugā is that the same file is exported differently depending on which device is used to export it - irrespective of the timezone set on the device.
The data was recorded using EmlidFlow on an iPhone, when it was originally recorded, the local time was at UTC+00:00
If I export the project in question today (UTC+01:00) using my iPad (which is now at UTC+01:00), then the data is exported as:
Solution status
Averaging start
Averaging end
Samples
FIX
2024-03-22 09:17:57.8 UTC+00:00
2024-03-22 09:18:07.8 UTC+00:00
51
If I export the same project today using Flow360 on my MacBook (UTC+01:00), then it is exported as:
Solution status
Averaging start
Averaging end
Samples
FIX
2024-03-22 10:17:57.7 UTC+01:00
2024-03-22 10:18:07.7 UTC+01:00
51
While the time may be technically the same, the output is inconsistent across multiple systems, which may lead to confusion - as it did with me.
Actually, maybe the bug is with EmlidFlow export, rather than Flow360 exportā¦
Iāve reproduced this behaviour, so Iāll discuss it with the team. Can you please share this particular project with me? You can also send it to support@emlid.com to keep it private.
Our devs have been investigating this behaviour and have found its root. For now, I canāt define an ETA for the fix, but Iād like to underline that the different offsets of UTC donāt affect the validity of the times as they mark the same time moment.
