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…
