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:

Select to expand quote

Timestamps

Date and time in are in Univeral Coordinated Time (UTC), not local time! Conforms to ISO 8601 specification for date/time representation.

From http://www.cl.cam.ac.uk/~mgk25/iso-time.html:

The international standard date notation is YYYY-MM-DD
The international standard notation for the time of day is hh:mm:ss
If a date and a time are displayed on the same line, then always write the date in front of the time. If a date and a time value are stored together in a single data field, then ISO 8601 suggests that they should be separated by a latin capital letter T, as in 1995-12-31T23:59:59.

Without any further additions, a date and time as written above is assumed to be in some local time zone. In order to indicate that a time is measured in Universal Time (UTC), you can append a capital letter Z to a time as in 23:59:59Z or 2359Z

The dates and times in these files follow this format (including the Z at the end) but they are not UTC dates, they are GMT+10 dates.

It seems that the current versions of Realspeed (at least since v1923) don't have this issue, but I have files processed by version 1804 that have the wrong dates in them.

Select to expand quote

Dylan72 said...

>>>>>>
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.

Sorry Dylan, this doesn't make sense to me, if the recording was done in a GMT+10 timezone, then surely that's the time it should be processed in to maintain the correct days????

Although I don't quite understand what's going on here, is it possible the trouble is caused by some people not setting their timezone? I have seen units still in GMT, not sure how that would confuse the issue.

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.