Wrong Timestamp in Recorded GPX-Track

[Manfred]

Hi!

Yesterday I recorded a bicycle tour. In the GPX-file time stamp of start is 12:41:32, but I started at 15:13 MEST.

Anyone else seeing this behavior?

Version: Osmand~ 1.9.#7531D

Regards
Manfred

[t.]

Using 1.9#7478D currently and did a quick test.

First timestamp is <time>2014-10-01T11:45:49Z</time> which equals 13:45 MEST which is the time I got the fix.

[Mihail Kasadjikov]

In GPX file the timestamp stores in GMT timezone. But it strange that you got a 2.5 hours shift instead of 2. Are you sure your phone has correct timezone? As I know the MEST timezone is GMT+2.
http://wwp.greenwichmeantime.com/to/abbreviations/index.htm

понедельник, 29 сентября 2014 г., 14:41:15 UTC+3 пользователь Manfred написал:

[Mihail Kasadjikov]

The GPX scheme: http://www.topografix.com/GPX/1/1/gpx.xsd
--- cut ---
<xsd:element name="time" type="xsd:dateTime" minOccurs="0"><xsd:annotation><xsd:documentation>
            Creation/modification timestamp for element. Date and time in are in Univeral Coordinated Time (UTC), not local time! Conforms to ISO 8601 specification for date/time representation. Fractional seconds are allowed for millisecond timing in tracklogs.
</xsd:documentation></xsd:annotation></xsd:element>
--- cut ---

среда, 1 октября 2014 г., 22:14:10 UTC+3 пользователь Mihail Kasadjikov написал:

[Manfred]

Hi Mihail!

Timezone is correct, the time of my phone may have been wrong, but time for timestamp should be taken from GPS-clock, not from phone, I think.
And yes, MEST is GMT (Zulu) +2.

Regards

[Mihail Kasadjikov]

Hi.

Yes. The timestamp in GPX should be taken from GPS, not from local phone time. And you see a 2 hours time shift.
All right.

пятница, 3 октября 2014 г., 3:31:13 UTC+3 пользователь Manfred написал:

[t.]

Hm seems an earlier post from me today has disappeared, where I had analysed that indeed the system time and not the GPS time is taken for the timestamp.

I had opened a ticket 2423 which however was closed already by the developer:

"It is implemented by design. On some devices it was a bug with GPS timestamp."

[verbage]

Hi, I am running into a similar timestamp issue with GPX logging, and it doesn't really make sense unless it can simply be attributed to a device with "a bug with GPS timestamp".

I am in the Central time zone (UTC-6), and my phone is correctly set to that time zone.  Yesterday at ~5:15 pm, i.e. 17:15 (UTC-6), or 23:15 (UTC), I started a track log.

The actual name of the GPX log file was "2016-01-04_08-15_Mon.gpx".  According to the OsmAnd wiki, GPX track logs are "named by ISO date and time".  But in this case the file name indicates that OsmAnd thought it was 08:15 (UTC), whereas in reality it was 23:15 (UTC).  So it was 15 hours off.

Internally within the actual GPX file, the timestamps showed values like "2016-01-04T14:15:58Z".  So OsmAnd was recording 14:15 (UTC) in the track log, whereas in reality it was 23:15 (UTC) as mentioned above.  So it was 9 hours off.

The point here is that OsmAnd was not correct in either case.  Furthermore, it was not even internally consistent.  For example, assuming it is a bug, the file name and internal timestamps should have both had the same incorrect values, but they were both different.  This is a little problematic (at least for me) because I often use my track logs as time-reference points.

I did look for time zone or potentially related settings in OsmAnd, and did not find any.

Ah, by the way, this issue described above is actually from using OsmAnd+ v2.2.4 on an Android v5.0.x device.  But I did notice similar problems on the free, OsmAnd this past summer, and that is what started this more detailed investigation.

Thanks for any comments you might have above this situation.

[verbage]

Hi again,

So I have some updated info about this situation because today I carried a second phone with me, and had the two phones simultaneously record track logs with OsmAnd+ v2.2.4.  The first phone (the one which resulted in yesterday's posting) is a Xiaomi Redmi Note 2 running a version of Android v5.0.2.  The second phone is an LG L41C which runs Android v4.4.2.  Both phones are set to my local time zone (UTC-6), and had the correct time and date set.  Both phones were running OsmAnd+ v2.2.4.

I started recording tracks at 16:30 local time (i.e. UTC-6), which means ~22:30 (UTC).

The file name of the GPX log from the first phone is "2016-01-04_17-06_Mon".  This is really weird as it is a whole day off (i.e. 4 Jan vs. 5 Jan), and the timestamp, which is supposedly recorded as UTC time according to OsmAnd documentation, is 17:06 when it should be 20:30.  Internally, within the GPX file, the track point timestamps are also screwed up.  The first one is "2016-01-04T23:06:44Z" when it should really be "2016-01-05T22:30:xxZ".

The file name of the GPX log from the second phone is "2015-11-05_10-30_Thu.gpx".  This is equally weird because it is from 5 Nov 2015, and, of course, we just rang in the new year.  The timestamp of "10:30" is sort of interesting because it should be 22:30 UTC, or 10:30 pm UTC.  So maybe that is sort of partially correct?  Internally, within the GPX file, the track point timestamps are also messed up, but sort of better than the first phone (depending on your perspective...).  The first track point timestamp is "2015-11-05T16:30:26Z".  So again, the date is way off, but what should be the UTC timestamp of "22:30xxZ" appears to be the actual local time, i.e. 16:30:xx.

At this point, it is not clear to me the pattern between the two devices vs reality, but whatever the case, it is disheartening to observe that neither of the devices get either the file name nor the internal timestamps correct.

I will add a third phone tomorrow to see what that does.  But for the moment, is there anybody else out there who is willing to look at this in the same level of detail with their device(s)?  I hope so because I consider this basic functionality, and it needs to be right.

[verbage]

So I have some more data by adding a third phone (an LG L34C running Android v4.4) to the mix.  I started all three phones simultaneously logging a track this morning at ~8:05 am local time (UTC-6), so 14:05 (UTC).

The first phone (Xiaomi Redmi Note 2) named the track log as "2016-01-05_16-34_Tue.gpx" and internally started recording timestamps as "2016-01-05T22:34:41Z".  So both the date and time are incorrect given OsmAnd documentation, which says that UTC time should be used.

The second phone (LG L41C) named the track log as "2016-01-06_07-03_Wed.gpx" and internally started recording timestamps as "2016-01-06T13:03:08Z".  So the date was correct, but both the times were incorrect.

The third phone (LG L34C) name the track log as "2016-01-06_07-02_Wed.gpx" and internally started recording timestamps as "2016-01-06T13:02:11Z".  So it is basically the same as the second phone--the date was correct, but both the times were incorrect.

There is some solace in seeing that the two LG phones provided parallel results.  But nonetheless, the overall results seem sort of disastrous if one is counting on OsmAnd to actually record timestamps correctly per its very own documentation, which says UTC times will be used.

Can anybody else confirm similar results?

[Toby Dickenson]

I have a nexus 4 running cyanogenmod 5.1.1. In the UK, so currently
GMT+0. The timestamps in the filename and on logged points are all
correct!

I have logged plenty of tracks in the summer (BST = GMT+1) and am
pretty sure I would have noticed if the times were wrong.

> --
> You received this message because you are subscribed to the Google Groups
> "Osmand" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osmand+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[verbage]

Thanks, Toby, for the clue!  So it sound like if the system time zone is set to GMT+0, the timestamps will come out correctly.  I will try that later today by setting one of the devices to the GMT+0 time zone, and recording a log.  If this is the case, i.e. the system time zone would have to be set to GMT+0 for accurate GPX log timestamping, well, at least it would be a possible workaround though not ideal.  Anyway, I'll report again later after I try this.

[verbage]

Just an update here, but a big (actually, gargantuan...) forehead slap by me may be necessary.

I did do logging yesterday afternoon again with two of the previously mentioned devices set to the local time zone of UTC-6, and the third device set to the GMT+0 time zone.  And then late in the evening, when I went to download the files, I did not see GPX log files in my tracks directories on any of the three devices.  Huh???  Well, it was too late to do anything at that point, but as I pondered the situation, I realized that OsmAnd had not yet written the files to the device.  So this morning, I read through the documentation for the trip recording plugin (http://osmand.net/help/HowToArticles.html#How_to_Record_Your_Movements_in_GPX_Format), and saw the comment that:

"To save track, open Logging services and tap "Save current gpx track". Tracks will never be lost. If they are not saved manually, they will be saved after the next start of the OsmAnd (even if OsmAnd crashed)."

That's when I realized I probably have been using the plugin incorrectly.  You see, what I normally did was the following.  To start a GPX track log, I would hit the button in the GPX widget at the top right of the screen, and the button would turn red.  To stop recording it, I'd tap the red GPX widget button, and choose the "Stop GPX logging" option.  You see, I never used the "Save current GPX track" option because I assumed (incorrectly) that on stopping the logging, it would close or write the GPX file on the device giving it the correct timestamp as the file name.  And that seemed to be the case because GPX track logs were automagically appearing in my tracks directories.  But I now realize they were probably automagically appearing given what is said in the instructions above--i.e. that the current buffer will be automatically saved after the next start of OsmAnd (if it is not manually saved).

So this morning, I recorded a track on the same three devices, and after stopping the logging, I went the extra step of choosing the "Save current GPX track" option on each of devices.  Lo and behold, each device saved the current track log with a file name that reflected the local time on the device, but internally, all three logs were recorded with the same, correct Z/UTC+0/GMT+0 timestamp.  I will try it again this afternoon, and go the extra step of saving the current GPX track log instead of just stopping the logging.  But since it worked correctly this morning, I suspect it will work correctly this afternoon.

All this said, there are still some inconsistencies that I am investigating because they do not make sense--for example, why would the tracks have very different internal timestamps previously?  Maybe this is a combination of not choosing the "Save current GPX track option", and also leaving OsmAnd loaded in the background vs. completely closing it with a task killer.  By completely closing it with a task killer, the next time it would start up it would automagically save the current buffer as per the documentation mentioned above.  But if the app is not completely killed, and logging is resumed later, there may be some internal confusion about the timestamps.  I will test this more, but this may be what user Manfred actually stumbled on, and provoked him to start this thread.

There are a couple of observations I make for posterity because they may help someone in the future.  The file name of the GPX tracklog is actually based on the local device time, but as an ISO date/time format string.  I was assuming (incorrectly) that the actual file name was supposed to be given as UTC+0/GMT+0, too.  But based on the reference pointed out by Mihail Kasadjikov, the actual file name of the track log does not have to be UTC+0/GMT+0, only the internal timestamps need to be.  In hindsight, this is obvious, but combined with the automagically named files that I thought were being created when I stopped GPX logging (and not by manually using the "Save current GPX track" option), this was definitely not clear.  The actual file system timestamp, however, will be reflective of when the file was written to the device.  For example, if you start a GPX log at 10 am, and the file is closed at 4 pm (either automagically or manually, as per above), the file system timestamp (not the file name) on the resulting file will be the latter.  Again, this seems obvious in hindsight, but combined with what I mentioned before, it only added to the confusion.

I will report back again in a few days after I further examine the issue about the different internal timestamps as mentioned above.