search

activityworkshop / GpsPrune

GpsPrune is a map-based application for viewing, editing and converting coordinate data from GPS systems.
GNU General Public License v2.0
71 stars 21 forks source link

myTracks time format support #81

Closed robjk closed 1 year ago

robjk commented 1 year ago

Hi,

The myTracks IOS app produces slightly odd timestamps of the form 2023-07-21T01:25:38.95100Z note the 5 digits of fractional time before the timezone... Full except of a tkpt below if you're interested.

This PR modifies the regex, adds a unit test as well as some (very) minor tidy-ups.

I'm very happy to change this to suit another approach if you prefer (for example I suspect fractional should support up to microseconds rather than this odd halfway between millis and mics).

trkpt from myTracks <trkpt lat="7.226303854543608" lon="79.8397121879995"><ele>7.875593766513052</ele><time>2023-07-21T01:25:38.95100Z</time><extensions><mytracks:speed>0.05727850071516458</mytracks:speed><mytracks:length>0.01794754256126502</mytracks:length></extensions></trkpt>

Thanks for the very useful tool.

(as an aside, I've now shifted to using the "GPX Tracker" IOS app but this PR allows me to tidy-up existing myTracks gpx files)

Cheers, Rob

activityworkshop commented 1 year ago

Thanks for this, I'll address the three issues separately:

1 - updating the test imports: yes, you're absolutely right, I'd committed a similar fix (97c2fbba2065a4de3849cdaa9ac310fffa2b735b) but not yet pushed

3 - redundant escaping of regex: yes again, this was escaping + and . inside the [], this doesn't change the runtime behaviour but you're right it's neater. Committed just now with f04d4ec751e3203d22ab5f841f5c05c6c8366a34

2 - 5 digits of fractional seconds in timestamps: not quite. I mean, if it made any sense to support sub-millisecond timestamps (which I'm not sure it does), it's not enough to just change the regex from {1,3} to {1,5}. It would also be necessary to extend the switch starting on line 268 so that these fractional seconds are incorporated into the object. Currently it only covers the cases 1,2,3 so for 5 digits the milliseconds would remain at zero, which definitely isn't correct. Unfortunately the rest of the code (including the use of java's Calendar) only deals with whole numbers of milliseconds so the best you could do is just chop off those extra two digits and ignore them - which is, again, not optimal.

Suggestions welcome!

robjk commented 1 year ago

Thanks for the feedback, I'm just in the process of relocating to a new country so I'll be unlikely to spend further time until I'm all setup again - I'll close the PR for now and resurrect later.