Position times
Time is stored without any timezone information. It's an absolute timestamp that can be then converted into local time when displayed.
Hi Anton
Thanks for that. Very useful though it does raise another issue to do with MySQL date/time fields which I may post separately. I’m using MySQL 5.6 BTW. Other databases and versions of MySQL may differ.
What I want to establish is what actually goes into each of the three fields.
On closer examination I see that servertime in tc_positions has a default value of CURRENT_TIMESTAMP which sets servertime to the current time of day for the database connection. Assuming Traccar doesn’t change that before inserting the record, and I see no reason why it should, then that means that servertime is indeed the time that Traccar processed the fix report.
Looking at the watch and osmand protocols, they both include just one timestamp in their fix reports, so that presumably is the time that goes into devicetime and fixtime, both as is.
So if I don’t know what time zone the tracker is set to but I do know what time zone the server uses, then servertime is the one to be relied on.
Sound about right?
Well, if your data is buffered and sent later, your server time will not match the location time.
True, but for the application I am working on, where the tracker was half an hour ago, or even 10 minutes ago, or the route it took to get there is of little relevance. We need to know where it is now.
FYI the app is to do with tracking small boats in open water for safety. They should be guaranteed a good view of satellites and the mobile coverage of the sailing area is known so, if I understand buffering correctly,it isn't going to come into it.
The bottom line is that people need to understand what Traccar is telling them and act accordingly.
If trackers are reporting a wrong timezone, that probably needs to be fixed.
Quite so, but the plan is for customers, over whom we have no little or control, to supply their own trackers. And you know what customers are like!
We can ask them nicely but sometimes they just won't listen. In reality I think the chances of devices reporting in anything other than UTC are slim but we only need one for chaos to unfold and us to spend time explain where they went wrong.
So, if it's alright with you, I'll use servertime. Or is there a reason why not?
BTW I'm not going to post separately about MySQL and date/times. The Traccar recommended MySQL connection string includes serverTimezone=UTC and, with servertime defaulting to CURRENT_TIMESTAMP it will always be UTC if my reading of the MySQL documentation is correct.
Thanks for your help.
You can use server time if that works for you.
I have same problem, ServerTime also the UTC time,
2023-09-30 08:23:33 INFO: [T1ed418c8: gt06 > 137.64.0.36] 78780512012e73000d0a
2023-09-30 08:23:43 INFO: [T1ed418c8: gt06 < 137.64.0.36] 7878231217091e061729cc019bcb4003c03dc819d057028a0a07d800333c00000000012f29bf0d0a
2023-09-30 08:23:43 INFO: [T1ed418c8] id: 359857085403194, time: 2023-09-30 08:23:41, lat: -14.99296, lon: 34.96132, speed: 13.5, course: 87.0
2023-09-30 08:23:43 INFO: [T1ed418c8: gt06 > 137.64.0.36] 78780512012f62890d0a
2023-09-30 08:23:53 INFO: [T1ed418c8: gt06 < 137.64.0.36] 7878231217091e061733cb019bcac203c0445228d053028a0a07d800333c00000000013059460d0a
2023-09-30 08:23:53 INFO: [T1ed418c8] id: 359857085403194, time: 2023-09-30 08:23:51, lat: -14.99289, lon: 34.96225, speed: 21.6, course: 83.0
2023-09-30 08:23:53 INFO: [T1ed418c8: gt06 > 137.64.0.36] 7878051201308aff0d0aServer Time
Local time: Sat 2023-09-30 08:31:44 CAT
Universal time: Sat 2023-09-30 06:31:44 UTC
RTC time: Sat 2023-09-30 06:31:44
Time zone: Africa/Blantyre (CAT, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: noMysql Time
now()
2023-09-30 08:31:09
I just want to confirm the contents of the time fields in tc_positions. Is this correct –
servertime = the time that Traccar server processed the position report
devicetime = the time that the device said it sent the report
fixtime = the time that the device said it recorded the fix
Unless the device is buffering, devicetime and fixtime are usually (always?) the same.
servertime can be a few seconds later.
servertime is always UTC (regardless of the server’s time zone)
devicetime and fixtime are the time zone of the device. That usually (always?) defaults to UTC but can be changed.
If the above is correct, in the case where users are providing and configuring their own trackers, potentially setting their own time zones, then, in order to obtain consistent fix times, the server operator is best advised to rely on servertime (provided being a few seconds out is not an issue). Is that correct?
Apologies if this is documented elsewhere; I have searched but not found.