#44 Wrong timestamp in GPX-File

Stefan Pflumm

When you set, for example, UTC+2 in BT 747 then two hours will be added to the UTC-Time of the gps timestamp, and then they will saved as, for example:
That's wrong, because the 'Z' means that this timestamp is UTC-Time. The correct way should be:
as in xsd:dateTime described.


  • Mario De Weerd
    Mario De Weerd

    Thanks for pointing that out.
    For the moment you can avoid that BT747 adds the offset to that time in the Advanced File Settings where you can select "Do not apply UTC offset" for the GPX format.

    In a way, the behaviour is what I wanted. I wanted to have the time look as 2 hours later. However, in your example, if I want the UTC time to maintain the same, the UTC time would have been:
    as BT747 added the '2 hours' and therefore, the 'correct' way would be:
    where the '+2' needs to be substracted (see below) to find the UTC time:

    Would you agree wit that?

    The logic behind actually adding the offset is that some programs do misinterpret the GPX datetime and do (did) not offer a means to easily correct the time to a 'local' time.
    Anyway, I'll consider this for a future modification (and potentially an extra option).

    For info:
    W3.org says somewhere:
    For example, 2002-10-10T12:00:00-05:00 (noon on 10 October 2002, Central Daylight Savings Time as well as Eastern Standard Time in the U.S.) is 2002-10-10T17:00:00Z, five hours later than 2002-10-10T12:00:00Z.

  • Stefan Pflumm
    Stefan Pflumm


    Oh yes, my example was wrong. You are right, the xsd:dateTime (or ISO 8601) contains localtime and offset and not UTC time and offset.

    The reason why i posted this 'bug' is because i want to collect gps data with local timestamps. With the current timestamp encoding, it's hard to figure out what the gpx timestamp really is: is it UTC or is it localtime, because i have no information about the user settings in BT 747.

    You have written that some programs may have problems with this change of the timestamp. But the first 19 characters of the timestamp doesn't change. For example:
    it's 17:32 UTC and you have set UTC+2 in BT 747. So currently your program write
    in the gpx file. With the offset, the timestamp changes only in the end:
    So it's not necessary to calculate something if you want localtime, it's just necessary when you want UTC, but that's not reconstructable without the offset. So i think the most programs should handle the timestamp with offset as good as without.