Client submitting "future" timestamps, server not updating current position.

I have noticed twice that one of my tracked phones, running the latest Traccar from F-Droid, with encryption enabled, would stop updating on the web site. Looking at the info for the device, it is apparent that it ends up logging a single point to a future date, which the web interface then displays as the "last" point. Note the line showing 2017-09-14 at 2017-08-28 11:49:35. This has happened twice in the last week.

017-08-28 11:48:15  INFO: [85AF2A07] id: 284469, time: 2017-08-28 11:48:13, lat: 37.43570, lon: -79.12602, speed: 0.0, course: 0.0
2017-08-28 11:48:55 DEBUG: [85AF2A07: 5055 < 174.226.135.69] HEX: 474554202f3f69643d3238343436392674696d657374616d703d31353033393335333333266c61743d33372e34333538333535266c6f6e3d2d37392e3132353937$
2017-08-28 11:48:55 DEBUG: [85AF2A07: 5055 > 174.226.135.69] HEX: 485454502f312e3120323030204f4b0d0a436f6e74656e742d4c656e6774683a20300d0a0d0a
2017-08-28 11:48:55  INFO: [85AF2A07] id: 284469, time: 2017-08-28 11:48:53, lat: 37.43584, lon: -79.12598, speed: 0.0, course: 0.0
2017-08-28 11:49:35 DEBUG: [85AF2A07: 5055 < 174.226.135.69] HEX: 474554202f3f69643d3238343436392674696d657374616d703d31353035333632373336266c61743d33372e34333536393333266c6f6e3d2d37392e3132363030$
2017-08-28 11:49:35 DEBUG: [85AF2A07: 5055 > 174.226.135.69] HEX: 485454502f312e3120323030204f4b0d0a436f6e74656e742d4c656e6774683a20300d0a0d0a
2017-08-28 11:49:35  INFO: [85AF2A07] id: 284469, time: 2017-09-14 00:18:56, lat: 37.43569, lon: -79.12600, speed: 0.0, course: 0.0
2017-08-28 11:54:36  INFO: [85AF2A07] disconnected
2017-08-28 12:00:55  INFO: [D76EC495] connected
2017-08-28 12:00:55 DEBUG: [D76EC495: 5055 < 174.226.135.69] HEX: 474554202f3f69643d3238343436392674696d657374616d703d31353033393336303535266c61743d33372e3433353230303432266c6f6e3d2d37392e31323536$
2017-08-28 12:00:55 DEBUG: [D76EC495: 5055 > 174.226.135.69] HEX: 485454502f312e3120323030204f4b0d0a436f6e74656e742d4c656e6774683a20300d0a0d0a
2017-08-28 12:00:56  INFO: [D76EC495] id: 284469, time: 2017-08-28 12:00:55, lat: 37.43520, lon: -79.12563, speed: 1.7, course: 94.6
2017-08-28 12:01:25 DEBUG: [D76EC495: 5055 < 174.226.135.69] HEX: 474554202f3f69643d3238343436392674696d657374616d703d31353033393336303835266c61743d33372e3433343936383537266c6f6e3d2d37392e31323538$
2017-08-28 12:01:25 DEBUG: [D76EC495: 5055 > 174.226.135.69] HEX: 485454502f312e3120323030204f4b0d0a436f6e74656e742d4c656e6774683a20300d0a0d0a

Simplest would be to discard points showing a "future" time stamp more than a few minutes into the future, though of course it would be interesting to know where this data comes from.

There is a configuration option to filter positions from future:

https://www.traccar.org/configuration-file/

That is working so far. Any additional troubleshooting I can attempt to determine why the client is sending those occasionally?

I can only think of two possibilities:

1. Wrong time on the phone for some reason
2. Phone or GPS module malfunction

First one should be easy to check. You've probably done it already.

Since it happens with only one uploaded point (possibly a few minutes worth of points) I have never seen this actually reflected anywhere else on the phone. But then I can't imagine how it would be broken in the client like this either.

Dead end! Thanks.

I have the same problem. With my phone it works, but friend's no. It did happen also to an another friend, but just once.

[ip censored] - - [17/Sep/2017:22:53:08 +0200] "POST /?id=976097&timestamp=3009581938&lat=[censored]&lon=[censored]&speed=0.0&bearing=0.0&altitude=65.30000305175781&accuracy=0.0&batt=95.0 HTTP/1.1" 200 32 "-" "Dalvik/2.1.0 (Linux; U; Android 7.0; SM-G950F Build/NRD90M)"

The unix time stamp is totally wrong, should be 1505681588.

You would need to provide some more information to investigate the problem. At least android logs.

Well if it will happen on a phone which I have physical access to, I will.
Currently I'm just writing the timestamp from the server when the location update arrives, instead of the client supplied one, with that I'm bypassing the problem of the Android client.