Messages

For all those suffering from the reported bugs, here is a workaround that leads to correct time values in exported GPX/KML/KMZ/CSV files (except that for CSV the time stamps are still 10 years off):

Disable automatic time zone on your phone and select a time zone that does not have a Daylight Saving Time (DST) at all but that results in the right offset from GMT, including the +1:00 DST offset.

For instance, CEST (Central European Summer Time = UTC+1:00+1:00) can be simulated by Cairo time (which is Eastern Europe Standard Time = GMT+2:00).

Of course I've checked that the time of my phone has been (automatically) set correctly, including time zone and DST activation.

Of course one can assume that the GPS timestamps as received by the phone are correct,

but the result when exporting tracks with your app are wrong. It looks like summer time correction often is applied twice, and sometimes not at all!



For instance, today I started recording a track in Prague at 10:20 local time, which is CEST. The timestamp of the first recorded trackpoint, when exported as GPS or KML, is 2018-05-24T07:20:17Z - one hour behind!!

The start time given in the GPX file is 2018-05-24T08:20:13Z, which is correct, while the start time in the KML file is 05/24/2018 09:20, which is one hour off in the other direction, so one hour ahead!

In the CSV export, things are even much more weird. For the start time I get 896080817, which apparently is May 29, 2008 07:20:03 UTC (10 years!!! and 1 hour behind), and similarly for all other times in the file.



There is definitely more that one bug in the way your app exports/reports times when DST is active. Just note the inconsistencies I've reported above - they cannot be explained by an error setting up my phone or by an Android bug.

I wonder why this bug report did not receive any response (by Orux or anyone else). The problem is still present.



Trackpoint time stamps by the GPS are off by one hour during daylight saving time (summer time): the times provided are one hour less than the real time. For instance, now it is 14:00 CEST, which corresponds to 12:00 GMT/UTC. When I start recording a track now, the starting time given in the meta data is correct (12:00), but the times recorded in the actual track start as 2018-04-07T11:00:00Z. Maybe this is a bug already in the Android GPS data provider because the same silly things happens also with the GPS Status app. It only happens when daylight saving time is active (for instance, it does not happen in winter and in time zones that do not use a DST). This bug occurs with the current version 7.2.11 of OruxMaps, but also with earlier ones (including 7.1.6).



If this is due a bug of Android, I suggest the following workaround: Compare the first timestamp that is about to be saved with the (correct) starting time obtained from the system and stored in the header. If the former is about one hour before the correct time, add one hour to each time stamp recorded.