31.10.2010, 16:20
(31.10.2010, 15:48)routeconverter Wrote: Da haben mich Nutzer überzeugt, daß das Verschieben eines Trackpunktes bedeutet, daß Datum und Uhrzeit nicht mehr stimmen können, da sie nicht so aufgezeichnet wurden - und deshalb gelöscht werden sollen.
Wenn ich Ausreißer dahin verschiebe, wo sie hingehören, dann stimmen die Zeitangaben durchaus, nur die Position stimmt eben nicht. Das passiert mir durchaus häufig, wenn ich bspw. in einem Gebäude bin oder in der Nähe einer Häuserwand oder ... Heißt das denn, ich müsste jetzt die Angaben händisch wieder hinzufügen? Hm ...
(31.10.2010, 15:48)routeconverter Wrote: Ich jage da Bugs unter Linux und Mac OS X und stellte deshalb derzeit Vorabversionen, die nur dafür geeignet sind, ins Netz. Vielleicht dauert das noch diese Woche, dann ist der Spuk vorbei ;-)
Ach so, ja dann ... :-)
(31.10.2010, 15:09)Wallaroo Wrote: und zeigte jetzt die korrekte Länge und Dauer trotz fehlerhafter Datums-/Zeitangabe an,
(31.10.2010, 15:48)routeconverter Wrote: Prima.
Nein, leider nicht prima. Die "falsche" Zeitangabe, wie ich eben meine festgestellt zu haben, scheint abhängig von der Betriebssystem-Zeitzone zu sein. Irgendwie interpretiert RC 2 wohl etwas, was es m. E. nicht sollte und was RC 1.xx nicht tat/tut.
Beispiel:
Ein Trackpunkt wurde 08.10.10 23:16:34 aufgezeichnet (UTC).
RC zeigte gestern an: 09.10.10 01:16:34 (UTC+2 = MESZ)
Hoppla:
Das zeigt er heute auch an, da müsste ja an sich 09.10.10 00:16:34 (UTC+1 = MEZ) zu sehen sein. Stützt meine Vermutung also nicht.
Was verschiebt die Zeitangabe wohl dann?
(31.10.2010, 15:09)Wallaroo Wrote: Liegt das wohl alles nur an meinem Aufbau, oder woran sonst?
(31.10.2010, 15:48)routeconverter Wrote: Nein, ich hoffe, das erklärt zu haben?
Danke vielmals für die bisherige Aufklärung :-)