Time Bug in Emlid Flow 360 export

Hi,

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

2024-03-22 09:17:57.8 UTC+00:00 2024-03-22 09:18:07.8 UTC+00:00

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:

2024-03-22 10:17:57.7 UTC+01:00 2024-03-22 10:18:07.7 UTC+01:00

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.

Collection Time

Start:22 Mar 2024 ā€¢ 09:17:57

End:22 Mar 2024 ā€¢ 09:18:07

Nick

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?

Joel

Hi Nick,

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 :wink:

Always think in UTC (Coordinated Universal Time).

Itā€™ll make you life easier if you think about it. My life has been referenced to UTC since the mid 70ā€™s.

Hi Nick,

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?

1 Like

Hi Kornel,

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ā€¦

Hope that clarifies whatā€™s happening.

Nick

1 Like

Hi Nick,

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.

1 Like

Hi Kornel,

No problem sharing the project. Is there a way to share the ā€˜originalā€™ thatā€™s on the Flow360 ā€˜cloudā€™ with you?

Or, would you like the exported project csv from the iOS app and also from Flow360?

Hi Kornel,

Iā€™ve sent an e-mail marked for your attention with a link to the project csvā€™s

Nick

Hi all,

Just an update: Iā€™m in touch with Nick via email about this topic.

Hi Nick,

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.

1 Like

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.