Time Parameter on Web interface showing future date (2092-07-29)

Jitesh6 years ago

Hi Anton,

I have a Traccar server running on AWS. I am using it to monitor around 100 vehicles and everything has been running fine until now. Recently two of my vehicles seems to be displaying incorrect time from far in the future 2092-07-29. I have tried a few things:

  1. Checked the positions table in database but none of the 3 date fields (servertime / fixtime / devicetime) has any dates in the future
  2. As a temporary solution restarting the server/application fixes the issue but it somehow reoccurs in a few days

Both the vehicles have been earlier running fine on a different server and have been recently ported onto my server. (Another thing I noticed is that both the devices have very close IMEI number)

Can you please guide me in the right direction to find the source of the problem.

Thanks
Jitesh

Anton Tananaev6 years ago

Use search.

Jitesh6 years ago

Hi Anton,

I have done that already and already have the fix in place for few months now (filter.future paramter) as below:

<entry key='filter.future'>3600</entry>
<entry key='filter.enable'>true</entry>

and probably that's why the database is not showing any incorrect date. The positions table shows no future data for the device. Also the devices table shows the lastupdate date as the recent most entry (Checking now I see it as 2019-02-09 05:44:09). but still in the web interface the date shows a future date (currently showing as Time : 2092-07-29 10:55:05) (Device uses GT06 protocol)

Only thing which helps in this case is to restart the traccar. On restarting the device behaves as if it has been newly configured showing time as Time
1970-01-01 05:30:00 and lat , lon as 0,0 and after sometime starts showing the correct position.

Anton Tananaev6 years ago

What do you see in logs?

Jitesh6 years ago

Checking yesterday's log, I see several times device has message similar to below:

2019-02-08 00:06:17 DEBUG: [708E8B88: 5023 < 223.24.187.173] HEX: 78780d010686916011130836054f1cc90d0a
2019-02-08 00:06:17 DEBUG: [708E8B88: 5023 > 223.24.187.173] HEX: 78780501054f0c1e0d0a
2019-02-08 00:06:17  INFO: [A4FC552F] timed out
2019-02-08 00:06:17  INFO: [A4FC552F] disconnected
2019-02-08 00:06:17 DEBUG: [708E8B88: 5023 < 223.24.187.173] HEX: 78780a134406030000055005040d0a
2019-02-08 00:06:17 DEBUG: [708E8B88: 5023 > 223.24.187.173] HEX: 787805130550d4450d0a
2019-02-08 00:06:17  WARN: Data truncation: Incorrect datetime value: '2092-07-29 05:28:11' for column 'fixtime' at row 1 - MysqlDataTruncation (... < QueryBuilder:477 < DataManager:448 < DefaultDataHandler:27 < ...)
2019-02-08 00:06:17  INFO: [708E8B88] id: 686916011130836, time: 2092-07-29 05:28:11, lat: 7.83026, lon: 98.34037, speed: 0.0, course: 0.0

and once it shows devicetime error:

2019-02-08 05:26:14  WARN: Data truncation: Incorrect datetime value: '2092-07-29 05:26:12' for column 'devicetime' at row 1 - MysqlDataTruncation (... < QueryBuilder:477 < DataManager:448 < DefaultDataHandler:27 < ...)
2019-02-08 05:26:14  INFO: [89C20BDB] id: 686916011130836, time: 2092-07-29 05:26:12, lat: 7.82465, lon: 98.34011, speed: 0.0, course: 0.0
Anton Tananaev6 years ago

You need to find where it originally came from.

Ernesto Vallejo6 years ago

I would say is more a device issue rather than a server issue. Check for other questions at devices' forum. I think similar situations have been solved by setting device to factory defaults and configure it again.

Jitesh6 years ago

Thanks for the suggestion. Will try it out.

Jitesh6 years ago

@Ernesto Vallejo, I tried factory resetting the devices, but unfortunately, the problem reoccurs. So the issue is somewhere else.
Do you think it can be a timezone issue as the application has instruments operating in different timezones?

Jitesh6 years ago

Update: After trying a lot of things, I finally just increased the filter.future parameter to 7200. As mentioned, server has vehicles in two timezones, one being 1.5 hrs ahead of other. so just tried increasing the future parameter to more than 1.5hrs and that seemed to have work