Older known location data overwrite newer ones

[supaeasy]

I have noticed this behavior for a long time now but was never sure I was not mixing up dates in my head. Now I can 100% confirm this:

From time to time recent location data gets replaced by older location data in the app (e.g. last location of car keys known Today at 7:19 changes to Last location yesterday when refreshing the app. An immediate refresh does not correct this. Sometimes a longer wait (>1 hour) will revert that, sometimes I have to wait for actual new location reports. I tried fetching last location only (my default is 7 days) but no changes (fetched 0 locations) there as well. Could something be wrong with handling what is "most recent"?

[GameEnder]

I am encountering the same same thing. It will suddenly change location back to a older spot then change to a new one. The Location count is still going up so it is reporting, but the map dose not update correctly.

What device are you using? Is it a NRF52 based device by chance?

[supaeasy]

Different Devices, all but one are NRF51 based. The other one is an ESP32-WROOM

[dchristl]

The issue here is that each report has two timestamps. One is the upload timestamp (already visible after encryption) and the other is the event timestamp (only visible after decryption), indicating when the location was recorded. The upload timestamp can be much later if, for example, there was no network available on the device. However, Apple sorts the reports not by the event timestamp but by the upload timestamp. This sometimes results in older location data having a newer upload timestamp. I'm already trying to work around this by sorting all reports again after decryption, so the latest location will be updated on the main page. However, this doesn't work when "Number of days to fetch location" is set to 'latest location only', as only the last report, i.e., the one with the latest upload, can be retrieved.

[supaeasy]

Oh that makes perfectly sense! Thank you, looking forward to your solution!

[supaeasy]

I have done some testing now and your explanation does not seem to fit entirely. There seems to be an internal sorting problem.

I have made best experiences when setting numbers of days to fetch to 1 instead of 7. Position data then shows very recent data and will update in an expected way. When I change that to 7 days and refresh for the first time, Position will be updated to an older time. When I refresh again (without changing days to fetch), this older position gets replaced with another timestamp: Sometimes older, sometimes newer than before but never to the actual most recent one from the 1-Day-Data-View. Replacing Data after refreshing stops at some point after 2-5 refreshes and settles with a position from the past. Never the most recent one. Even though while refreshing, the correct most recent date flashes before it gets replaces so it surely is there. Changing number of days to fetch back to 1 Day fixes this.

[dchristl]

Perhaps there is still an issue with sorting here. I'll take another look to see if I can find anything. Unfortunately, I'm currently short on time. Thank you for the research and for reproducing the issue.

[dchristl]

I was able to replicate the issue, which likely occurs when either Apple sorts incorrectly (in all my retrievals and tests, it has never done so) or when new locations are included in the retrieval. I'm leaning towards the latter scenario. For instance, an older report might be prioritized because the iPhone, responsible for gathering the data, was briefly offline, resulting in a timestamp change. I've implemented a hotfix for this, which is already available on the GitHub page. Could you please test it out and provide feedback? I haven't been able to replicate the issue with any of my devices, perhaps I have too much coverage with neighboring Apple devices. If it works, I'll update the Android app as well.
Thanks.

[dchristl]

Fixed in v.2.20