Opened 12 years ago

Closed 12 years ago

#1339 closed defect (fixed)

Potlatch incorrectly handle GPX timestamps with fractions of second

Reported by: dtbow Owned by: richard@…
Priority: minor Milestone:
Component: potlatch (flash editor) Version:
Keywords: GPX timestamp fraction second Cc: Shaun McDonald


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

Change History (3)

comment:1 Changed 12 years ago by Richard

Potlatch doesn't claim to support all the ridiculous intricacies of XML - the 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?

comment:2 Changed 12 years ago by Shaun McDonald

Cc: Shaun McDonald added

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.

comment:3 Changed 12 years ago by Richard

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.