Open flock-vi opened 2 months ago
This is less a bug in QMapShack more one in the originating app. There is a certain understanding on how to code milliseconds in time stamps. See https://qthub.com/static/doc/qt5/qtcore/qtime.html#toString
Also have a look at the code:
If you think you can do better without breaking other formats feel free to provide a PR.
Maybe we can check against a regex to distinguish between z
and zzz
.
IMHO this seems not correct in this case
if (timetext[i + 1] == '0') {
But I can not oversee all the other cases where QDateTime IUnit::parseTimestamp
is used and possible sideeffects!
With regex code could be:
const QRegExp hasTrailingZeroRE(".*(\\.\\d*?[1-9])0+.*");
if(hasTrailingZeroRE.exactMatch(timetext)) {
format += ".zzz";
} else {
format += ".z";
}
}
I have checked regex with https://regex101.com/r/jgGc1C/2
.0 ==> z ==> valid in QMS
.00 ==> z ==> valid in QMS
.000 ==> z ==> valid in QMS
.1 ==> z ==> valid in QMS
.12 ==> z ==> valid in QMS
.123 ==> z ==> valid in QMS
.01 ==> z ==> valid in QMS
.001 ==> z ==> valid in QMS
.10 ==> zzz ==> invalid in QMS, 3 digits expected
.100 ==> zzz ==> valid in QMS
.120 ==> zzz ==> valid in QMS
Describe the bug
Gpx-File: Trackpoints with timestamps with less than 3 digits after the decimalpoint give an error, when the first of those digits is 0
What have you done to circle down the problem?
Different timestamps but I only tried it with Version 1.17.1
To Reproduce
Import "Test.gpx" Have a look at the trackpoints less than 3 digits, first one not equal 0: ok less than 3 digits, first one equal 0: "Ungültige Zeitmarken!"
Expected behavior
might work with each timestamp
Screenshots
Attachments
Test_gpx.txt
Tracebacks
comment: # (Add your backtrace below if you have one. If QMapshack crashes the fastest way to get help is a backtrace. For Linux see: https://github.com/Maproom/qmapshack/wiki/TroubleShooting#create-a-backtrace-of-a-crash-on-linux. For Windows it would need a debug build and running QMapshack in Visual Studio.)
Desktop
Additional context