The timestamps that you get together with the updated position/velocity/... e.g. from geoclue-position-get-position() as unix times in seconds. For apps that request updates at a high rate, this will lead to inaccuracies when calculating e.g. speed. Having milliseconds there would be nice (e.g. from clock_gettime). This can't be fixed in the current API. As there are also other limitations in the current signaling, this could be addressed in a new signaling api that would e.g. provide aggregated information updates as a variable data structure (hash table).
Now that I am thinking more about it, applications hsould probably be fine with seconds. Applications should not really need to calculate speed, but rather listen to velocity updates and get the speed from that. WONTFIX?
True that velocity is not very good use case since most positioning solutions can provide better estimate using doppler etc. There can be many other use cases; if you e.g. track your path it would be a shame to round your waypoints' timestamps to even seconds.
Do many GPSs support more than one position per second? None of the ones I have can do that, unless it's a custom extension to increase the reporting rate.
It's not about how often you get updates, it's the exact moment of the fix. That is still good to know information. Furthermore we may have other methods than GPS that we want use in future. So this probably comes bigger problem later on.
(In reply to comment #4) > It's not about how often you get updates, it's the exact moment of the fix. > That is still good to know information. Why is knowing the exact moment of the fix such a problem? > Furthermore we may have other methods than GPS that we want use in future. So > this probably comes bigger problem later on. What other methods?
Closing all bugs on old geoclue. If your bug still applies to new geoclue, please do re-open, I really don't have time to go through each and every bug and evaluate separately. :( Apologies for any inconvenience caused by this change.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.