Anpassen der Uhrzeiten

[ragnar76]

Wie man auf dem Bild in #157 sehen kann stimmen die Uhrzeiten irgendwie nicht, in meinem Fall hängen die 2 Std. hinterher (ich fahr bestimmt nicht um halb 7 los, da dreh ich mich nochmal 30 Minuten lang um). Ich denke da ist irgendwas mit den Zeitzonen im argen. Kann man das irgendwie anpassen?

[martin-ueding]

Das grundsätzliche Problem ist leider, dass Dateien häufig ziemlichen Quatsch enthalten. Zeit ist immer furchtbar. Jetzt ist es bei mir gerade 13:39 Uhr. Das kann man auf mehrere Weisen ausdrücken:

• "13:39" hat keine Zeitzone, man nennt das "time zone naive". Wie man das in andere Zeitzonen umrechnet ist unklar, die Zeitzone ist "lokal".
• "13:39+0200" hat die Zeitzone Berlin (Sommer). Hier ist klar, wie man das umrechnet aber auch, was die lokale Zeit ist. Man kann die Zeitzonen-Information einfach löschen und hat das, was damals auf der Uhr stand.
• "11:39+0000" oder "11:39Z" ist die Angabe in UTC (Zulu) umgerechnet. Das bezeichnet den gleichen Zeitpunkt, aber hat eine andere Zeitzone, die erstmal in meine lokale Zeitzone umgerechnet werden muss.

In den Dateien steht jetzt leider alles mögliche drin. Manche Geräte nehmen in UTC auf, schreiben das aber nicht dran. Somit muss man annehmen, welche Zeitzone das wohl gewesen ist und in die lokale Zeitzone konvertieren.

Oder sie schreiben es dran, dann muss man in die lokale Zeitzone konvertieren. Aber dazu muss man wissen, was die eigene Zeitzone für diese Aktivität war. Wenn ich immer in Deutschland aufgenommen habe, so habe ich je nach Zeitpunkt im Jahr auf +0100 oder +0200 erhalten. Jetzt ist Sommerzeit und die Zeitzone "Berlin" ist +0200. Wenn ich das konvertiere, dann erhalte ich nicht das, was zur Aktivität auf der Uhr stand. Wenn ich das ganze Datum nach "Berlin" konvertiere, dann kommt es richtig raus.

Jedoch war ich auch in China joggen. Wenn ich diese Aktivitäten auch nach "Berlin" umrechne, dann stimmen die Zeiten wieder nicht. Ich war ja wirklich in einer anderen Zeitzone. Ähnlich ist es bei +0000/Z. Wenn man wirklich im Winter in UK war, dann ist das wirklich die lokale Zeitzone.

Man müsste jetzt noch die Längen- und Breitengrade der Aktivität berücksichtigen, auflösen welches Land das zum Zeitpunkt der Aktivität war, welche Zeitzone dieses Land zu diesem Zeitpunkt hatte, und das konvertieren. Dazu braucht man aber noch externe Daten, die ich nicht habe.

Falls deine Aktivitäten explizit UTC/+0000/Z als Zeitzone haben und du nur in der Zeitzone "Europa/Berlin" unterwegs bist, könnte man sich überlegen ob man alle Zeiten nach "Berlin" lokalisiert und danach die Zeitzone verwirft. Das hat aber wieder Probleme mit anderen Situationen, müsste man also konfigurierbar machen.

Alles eher kompliziert, weil wir eben zwischen Zeitpunkten und Uhrzeiten trennen müssen. Hier für diese Auswertungen sind die Uhrzeiten wohl interessant, manche Aufnahme-Programme setzen aber den Fokus auf die Zeitpunkte.

[ragnar76]

Das Tool was ich verwende (Geo Tracker für Android von Ilya Bogdanovich ; https://play.google.com/store/apps/details?id=com.ilyabogdanovich.geotracker&pli=1) nimmt wohl in Zulu Zeit auf (2024-09-10T08:31:01Z). Wäre es möglich irgendeine Art von Umrechnung einzubauen?

[martin-ueding]

Man kann da letztlich alles einbauen. Aber man müsste entscheiden, was man machen möchte. Man müsste angeben, in welcher Zeitzone man die Zeiten interpretieren möchte und in welche Zeitzone man sie lokalisieren möchte. Dabei müsste man dann eine Stadt angeben, damit auch die Sommer-/Normalzeit richtig berücksichtigt werden kann.

Soll das dann auf alle Aktivitäten angewandt werden? Was passiert, wenn du mal mit einer anderen App aufnimmst, die nicht in UTC aufnimmt? Und was ist mit meiner Aktivität, die ich in Peking aufgenommen habe? Die soll ja eben nicht auf die Berliner Ortszeit konvertiert werden. Das Problem ist letztlich mit der App, die sollte besser in lokaler Zeit aufnehmen.

Einen Spezialfall programmieren kann man machen. Aber das ganze so allgemein zu machen, dass es für andere Nutzenden sinnvoll bleibt, ist dann schwerer. Man könnte ein Plugin-System bauen, bei dem man dann eigenen Python-Code für die Konvertierung einliefern kann. Aber das erfordert dann auch schon viel Programmierkenntnis für die Nutzenden.

Ich kann gerne versuchen etwas für dich einzubauen. Wir müssen aber wirklich genau definieren, was da passieren soll.

[martin-ueding]

Kannst du benennen, welches Mapping für Zeiten du für deinen Fall brauchst?

[ragnar76]

Gute Frage.... Wenn ich in die GPX Datei schaue und mir den Tag ansehe dann geh ich davon aus dass das Zulu Zeit ist (anhand des "Z" am ende der Uhrzeit.

<time>2024-09-27T13:22:47Z</time>

[michael-hatz]

Hi Martin,

das mappen der Zeitzone aus GPX-Daten sollte recht einfach sein. Die GPX enthält ja Geokoordinaten und es gibt einfach zu nutzende Libraries dafür, diese etwa:

https://github.com/jannikmi/timezonefinder

es ist wirklich simpel:

`from timezonefinder import TimezoneFinder

tf = TimezoneFinder() # reuse

query_points = [(13.358, 52.5061), ...]
for lng, lat in query_points:
tz = tf.timezone_at(lng=lng, lat=lat) # 'Europe/Berlin'`

Das Thema Sommer/Winterzeit kannst du auch über time bzw. pytz abfragen. Du hast ja das Datum und die Zeitzone und auf der Basis kannst du abfragen, ob in der jeweiligen Zeitzone zum jeweiligen Datum gerade DST war oder nicht.

Ich glaube aber, dass die wirkliche Frage ist, ob du diese zusätzliche Komplexität mit in Geoactivity aufnehmen willst. Klingt erstmal nach einer sinnvollen Sache, aber gerade Zeitzonen haben so viele Edgecases und werden so merkwürdig verwendet, dass definitiv irgendwo andere Issues entstehen werden. Es klingt eher so als ob es sinnvoller wäre die GPX-Dateien vor dem Import zu fixen und mit der korrekten Zeit zu versehen. Dazu müsste es ja auch diverse Werkzeuge geben, etwa zur Massenbearbeitung der Uhrzeit und am Ende muss man hier dann das Rad nicht neu erfinden.