Potlatch incorrectly handle GPX timestamps with fractions of second #1339
Comments
|
Author: Richard Potlatch doesn't claim to support all the ridiculous intricacies of XML - the [http://trac.openstreetmap.org/browser/applications/editors/potlatch/gps.as#L93 date parser] basically looks for yyyy-mm-ddThh:mm:ssZ. It should be pretty elementary to support fractional seconds, but shouldn't you have a Z at the end to indicate UTC? |
|
Author: smsm1 If you don't have a Z at the end then it is in local time. TrackMyJourney records the tracks in local time instead of UTC for example. |
|
Author: Richard I've removed the need for the 'Z' in a certain position so that should fix it (will be deployed with API 0.6, Potlatch for API 0.5 is frozen). It won't actually use the fractional part of the second, but if you're surveying to sub-second accuracy you probably shouldn't be using Potlatch anyway. ;) |
Reporter: dtbow
[Submitted to the original trac issue database at 9.16pm, Friday, 14th November 2008]
I have uploaded a GPX file with track point timestamps going up to fractions of second. The file was imported with no errors, however when I press edit on the web site, Potlatch shows it to me as if I have the first point in the GPX being somewhere far away (sometimes north-west, sometimes north-east, depending on track but constant for a track). I checked manually, the first point is where it should be (no such big error). The GPX view (clicking on the file name in the list of GPX tracks) shows the track correctly, just the Potlatch does it wrong (though I haven't tested with JOSM or similar).
For a sample look e.g. at this track: http://www.openstreetmap.org/user/dtbow/traces/250801
I have fixed in the meantime my application to not provide fractions of second, but in general, the GPX standard doesn't forbid doing it.
The text was updated successfully, but these errors were encountered: