Timezone Aliases Loading Error After Upgrading from Traccar 5.12 to 6.1
I believe the warning is coming from here:
As for the database timezone, there were no changes and it's completely unrelated to this warning.
Thank you, Anton.
In addition to updating Traccar, I took the opportunity to update other packages on my OS (Rock Linux) and perform a reboot on my servers.
After restarting Traccar, the error message regarding the "inStream parameter" did not occur again. However, I've noticed that the data is still being saved in the database considering my timezone. It seems there really was no connection between the two issues, but I'm still intrigued to understand what might have happened.
For now, I think it might actually be better to have the information in my timezone as this will eliminate the need to use date_sub in my direct database queries. However, I will need to include it in queries referring to positions before today. This adjustment simplifies some aspects of data handling but requires changes for historical data.
I would be interested to hear if anyone else has experienced similar behavior.
Is your server timezone set to UTC or UTC -3?
SwayDev, it is UTC-3
Hello guys,
I've noticed an inconsistency. While most devices are recording timestamps with a UTC -3 offset, one specific device is recording timestamps in pure UTC. Here's an example with the current time:
- Local Time (UTC -3): 2024-04-24 11:07:15
- UTC Time: 2024-04-24 14:07:15
Query from Traccar database:
SELECT * FROM tc_positions ORDER BY id DESCQuery result:
After a period, it has started to alternate back to UTC -3 on its own. It seems to switch between UTC and UTC -3 intermittently.
I can see some errors from log:
2024-04-24 01:00:13 ERROR: Main method error - Validation Failed:
1 changesets check sum
changelog-4.0-clean::changelog-4.0-clean::author was: 9:df72baf1ad55ac0110e3525d3d6b6309 but is now: 9:29260b7c580835a4006cb8c8303f753e
- ValidationFailedException (... < DatabaseModule:96 < <gener:-1 < *:-1 < ... < MainModule:129 < ...)
2024-04-24 02:06:25 WARN: JAXBContext implementation could not be found. WADL feature is disabled.
2024-04-24 10:14:53 ERROR: An I/O error has occurred while writing a response message entity to the container output stream. - The part /xl/worksheets/sheet1.xml failed to be saved in the stream with marshaller org.apache.poi.openxml4j.opc.internal.marshallers.DefaultMarshaller@6e54bb9f. Enable logging via Log4j 2 for more details. - OpenXML4JException (... < SummaryReportProvider:189 < ReportResource:229 < *:98 < ... < OverrideFilter:49 < ...)
2024-04-24 10:15:19 ERROR: An I/O error has occurred while writing a response message entity to the container output stream. - The part /xl/worksheets/sheet1.xml failed to be saved in the stream with marshaller org.apache.poi.openxml4j.opc.internal.marshallers.DefaultMarshaller@5a20c8f9. Enable logging via Log4j 2 for more details. - OpenXML4JException (... < SummaryReportProvider:189 < ReportResource:229 < *:98 < ... < OverrideFilter:49 < ...)
2024-04-24 10:16:12 ERROR: An I/O error has occurred while writing a response message entity to the container output stream. - The part /xl/worksheets/sheet1.xml failed to be saved in the stream with marshaller org.apache.poi.openxml4j.opc.internal.marshallers.DefaultMarshaller@51be3acf. Enable logging via Log4j 2 for more details. - OpenXML4JException (... < SummaryReportProvider:189 < ReportResource:229 < *:98 < ... < OverrideFilter:49 < ...)
2024-04-24 10:16:12 ERROR: An I/O error has occurred while writing a response message entity to the container output stream. - The part /xl/worksheets/sheet1.xml failed to be saved in the stream with marshaller org.apache.poi.openxml4j.opc.internal.marshallers.DefaultMarshaller@57b17957. Enable logging via Log4j 2 for more details. - OpenXML4JException (... < SummaryReportProvider:189 < ReportResource:229 < *:98 < ... < OverrideFilter:49 < ...)
2024-04-24 10:59:55 WARN: Error loading timezone aliases: inStream parameter is nullI've noticed that there are no corresponding entries in the logs for some data points that were inserted into the database at UTC times.
For example, from the logs, there's no record of any data received from device id 867 at 2024-04-24 14:07:12 (UTC Time), which should correspond to the entries in the database.
I'm puzzled as to where this data is coming from, as there seems to be no trace of these data packets being received at the times logged as UTC. Does anyone have any insights or theories that could explain how data with no apparent origin is being recorded in the database?
It must be in the logs somewhere.
@Anton Tananaev, I can't find anything with this timestamp or something next to it.
An important detail: Specifically in these records, we do not have the address in the tc_positions table, which indicates that reverse geocoding was not requested to my nominatim server.
I selected one of the entries from tc_positions that were not found in the log and have the "incorrect" servertime. I then looked for another entry with similar information (latitude, longitude, altitude, speed, course, attributes) and found another record that is almost identical, except for the timestamp of the servertime. However, it makes a lot of sense that it could somehow be duplicated, see:
Latitude and Longitude are the same one for both.
Once you find it in the logs, we can continue the conversation from there.
@Anton, if this information is in the logs, I would expect to see (at least):
- uniqueId (id)
- time (fixtime)
- lat (latitude)
- lon (longitude)
- speed
- course
So, if I search in the log for deviceId and course = 290, I should find the information, right? I didn’t consider lat and lon because I see that these values might be rounded in the log but have more decimal places in the tc_positions table.
Well. Given that the uniqueId is 865XXXXXXXXX157 and the course = 290, I run the following grep in the log:
grep "865XXXXXXXXX157" /opt/traccar/logs/tracker-server.log | grep "course: 290"It return 2 entries:
But, on DB we can see the "duplicated" info:
I don’t know what I’m missing here, could this information be represented differently in the log file?
Don't really have any ideas.
Hello everyone,
I recently upgraded our Traccar installation from version 5.12 to 6.1, and I've encountered this warning in the logs:
WARN: Error loading timezone aliases: inStream parameter is nullAdditionally, there has been a change in how timestamps are handled in the database. Before the update, the positions were saved in the database considering UTC time. However, after the update, the positions are being saved with UTC-3 (which is my local timezone). This has led to an unusual visualization where some vehicles appeared as if their last location was in the future.