Position timestamps always 0 milliseconds

[pcloof]

Hi there,

At first, thanks for this cross-platform plugin!

I set up location updates every few seconds and noticed in my logging that the time stamps of the received positions have all zeros for the digits for the milliseconds and below, so all time stamps are effectively rounded or truncated to whole seconds. I just debugged my application to verify that I don't apply any rounding whatsoever in my application. When debugging the value of the timestamp within event handler method PositionChanged, the first time the breakpoint hits, the timestamp actually has a non-zero milliseconds part, but from then onwards, all received position updates have exactly 0 as millisecond part. When testing this outside recently, I waited until GPS signal was found and then I recorded 631 location updates over the time span of half an hour and literally all timestamps have exactly 0 millisecond part.

When debugging this thoroughly, I found out that the location changed handler is called twice for each update, but someone already created an issue for that. But I mention it to say that on both two calls of the first location update, the millisecond part is the same, non-zero value. On all subsequent (double) calls, the value is always zero.

Bug Information

Version Number of Plugin: 4.5.0.6 Device Tested On: Sony XPeria XZ1, running Android 9 Simulator Tested On: n/a Version of VS: Community 2017, version 15.9.8 Version of Xamarin: 4.12.3.80 Versions of other things you are using: XF 2.5.1, .Net Standard 2.0

Steps to reproduce the Behavior

My setup: I have a Xamarin Forms solution with a *.Droid project that runs the Android app. The app starts a foreground service that tracks the user's location. The internal code of the foreground service, including the class that handles the location updates, resides in a .Net Standard class library project.

1. Setup location requests using "await CrossGeolocator.Current.StartListeningAsync" method with a minimum time between requests of 5 seconds and a minimum distance difference of zero. Furthermore, I set "CrossGeolocator.Current.DesiredAccuracy = 50".
2. Of course, ensure permissions are granted, the GPS is turned on etc, such that location updates are actually received.
3. Subscribe to the PositionChanged event with a method and debug within that method and check within the PositionErrorEventArgs the value of Position.Timestamp.Millisecond.

Expected Behavior

The Millisecond part of the location timestamps shows a random integer value between 0 and 999 between different location updates, or else slightly varying values close to a certain value, when the updates are requested every X seconds.

Actual Behavior

The Millisecond part is some random (non-zero) value on the first location update, but it is zero on all later location updates.

Code snippet

// Called in constructor CrossGeolocator.Current.DesiredAccuracy = 50;

internal async Task StartListeningAsync() { if (!CrossGeolocator.Current.IsListening) { await CrossGeolocator.Current.StartListeningAsync(TimeSpan.FromSeconds(5), 0); CrossGeolocator.Current.PositionChanged += PositionChanged; } }

private void PositionChanged(object sender, PositionEventArgs e) { // <---- breakpoint here // my handler code }

Screenshots

[om297]

Did you get anywhere with this? I'm seeing the same

[pcloof]

Did you get anywhere with this? I'm seeing the same

No, I set it aside for now in the hope to get a reaction. I don't see any workaround since I simply can't make up for missing data.

[jamesmontemagno]

We just use whatever is returned: https://github.com/jamesmontemagno/GeolocatorPlugin/blob/master/src/Geolocator.Plugin/Android/GeolocationUtils.android.cs#L75

You could just set it to the current utc as that is when it occured. Nothing the library can do if it isn't returned.

[pcloof]

Thanks for answering. My problem behind it is that average speed computations generally start out too low and climb towards the 'real' value when time progresses, which indicates to me that the time stamps assigned to obtained GPS locations are too late. I hoped that the returned time stamp would be more accurate than measuring the current time myself, since getting a GPS location takes some amount of time, so should the time stamp be the start time of the location request, or the return time, or maybe half way? I was hoping that the provided time stamp would be somewhat accurate in this regard. Maybe there is so much uncertainty that accurate millisecond precision is impossible.

[chrisfoulds]

You will have to roll your own and also each device on Android may have different GPS chips and accuracy so you will get massive differences