I'm revisiting GPX files (as I do) on the ka72 site, and have noticed that files that have been output by Realspeed or GPSARPro (and I only have a few samples of these) seem to have had their dates and times altered to adjust for the time zone of the track. (Normally, when a device records a GPS file, it writes the date and time in GMT/UTC time, not adjusted for time zone.)
There is no indication in the file of what time zone the track might be in (apart from making an educated guess), and it is a royal pain.
Can anyone explain this phenomenon?
Can't answer your question dylan, but just to clarify, do you mean there's no timezone indication of the realspeed/gpsar saved files, or the files from the GPS?
I know the GT's have an input for timezone, so that could be in there somewhere.
I've just tried saving one of Kellie's SBN files as a GPX file with Realspeed, and it maintained the correct date/time.
What I have is some GPX files that have been submitted to the KA72 website. Although the sailing sessions were on a single day, they got split across two "days" because the date/time information in the file is incorrectly GMT+10 instead of GMT. You can see one of these files at www.ka72.com, one of the most recent submissions from Golden Beach is split across the 9th and 10th of March, although actually the sailing all took place on the 9th of March.
I don't have the original files from the GPS, only the files that have been submitted to the website, but it's not the first time it has happened. It always seems to be with files that have been saved out of RealSpeed or GPSARPro.
Dylan.
From the GPX file spec:
I think that what Dylan is saying is that some versions of some programs change the time from GMT to what the local time is, and then save that as GMT.
For example, right now it's 23:05 Western Daylight Saving time, so my GPS would record this as 14:05 GMT.
A program might read this, interpret what timezone I'm in, then save the time as 23:05 GMT (not 23:05 Western Daylight Saving Time).
Is this right Dylan?
As a programmer I can totally understand how such a bug might appear, and stay unnoticed for years.
Yes, nebbian, you've got it. That's exactly what I mean.
The speed reader site has to assume that since the date and time stored in the file is in UTC format (with the Z at the end.) So it works out that you are,for example, in approximately time zone GMT+10 (by your coordinates) and adds ten hours to each record in order to get an approximate "local" time.
This then allows the site to split files into multiple sessions over multiple days.
Which is all stuffed up if your dates have been modified by the software. You end up getting 20 hours added to the original date, ten by the site, and ten by something else (an old version of Realspeed maybe, or maybe some other thing.)
It seems like the present version of Realspeed doesn't do this, and I'm not even certain that the old one does this, but it seems like a possibility. I don't own GPSAR so I can't check that.
The real issue here is that old GPS's had their own timestamp modification, so the programs needed to implement a workaround so that different tracks could map to the same day. The correct solution is to set the GPS's to write the data in GMT, and never rewrite the date in the datafile.
You would only rewrite the date when displaying it on-screen -> which has the nice benefit of using a corrected timezone database, rather than the fudge factor of say +10.
I guess the problem is that the GPX file is presenting the date as GMT, when actually it is not GMT, and there is no way of knowing whether it is or not.
I could infer that the date is wrong, by guessing that people don't usually start windsurfing at 10pm, through to 2am, but that doesn't always work out.
