Ich häng’ mir hier mal ran weil’s thematisch ähnlich ist:
Auf dem Weg nach Litauen wurde in Polen eine ETA angegeben die eine Stunde hinterher hing.
Litauen ist +1 Stunde zu D und PL. Sollte ETA nicht Ortszeit des Ziels sein?
Weil das aktuell nicht so ist kam es zu zeitlichen Mißverständnissen im Telefonat mit einem Campingplatz was die abendliche Ankunft ( = arrival ) angeht.
Mit überschreiten der Grenze wurde die ETA dann korrigiert, da war’s aber schon zu spät…
Interessanter Fund, ja würde schon Sinn machen, wenn die ETA Ortszeit wäre.
Ok, erklär mal wie das ohne extra API oder komische Dependencies geht und dann noch als easy fix durchgeht . Klar können wir das selber bauen, aber das ist nicht mal so eben gebaut. Bei Zeitzonen liegt der Teufel im Detail.
Wir haben noch ein paar zusätzliche Requirements, daher habe ich keine passende Dependency gefunden. Eine extra API will ich dafür auch nicht anzapfen müssen.
Ich glaube das macht mehr Probleme als es lösen würde. Ich bin häufiger zwischen Spanien und Portugal gewechselt , immer eine Stunde Differenz. Der nächste moniert dann das zwischen 10:00 und 14:00 keine 3 bzw 5 Stunden liegen
Das hab ich nicht verstanden. Meinst du, dass das Anzeigen von ETA in der lokalen Uhrzeit des Ankuftsorts mehr Probleme dem User bereiten wird, als die lokale Zeit der aktuellen Position??
Inwiefern? Also so wie es jetzt ist, ist für mich ein klarer Bug.
Ich glaube die Erwartungshaltung ist für mich an der Stelle nicht ganz klar. Aus dem Bauch raus würde ich sagen, lokale Zeit vor Ort wäre eher richtig. Ich denke man kann für beide Seiten das passende Argument finden.
Ich finde Hampics Argument auch valide. Ich schaue auf die Uhr, sehe ich komme um 19:00 an und denke: wow, noch 5 Stunden? Dabei sind es nur noch 3 oder 4 Stunden.
Bei Flügen hast du aber auch oftmals viele Stunden Verschiebung und viele Stunden Flug. Ich finde das ist nicht 1:1 vergleichbar. Aber:
Nur weil er ETA falsch nutzt. Denn dafür hat man ETE;)
Und der Usecase, wo man sich ständig zwischen 2 zeitzonen bewegt, sollte ein Bruchteil der Kurviger Nutzer betreffen
Genau, und daher braucht es so etwas nicht. Und die Kollegen die von der Zeitumstellung überrascht werden, sind nochmals weniger. Und die Kollegen die nicht in der Lage sind so etwas zu antizipieren, die sind hier namentlich bekannt.
Ich hab aus Interesse mal kurz geschaut wie GMaps das macht. Die zeigen bei Wechsel der Zeitzone bei der Ankunftszeit zusätzlich die neue Zeitzone an, dann wird es wirklich unmissverständlich und alles wären glücklich denke ich
…wenn ich zwischen Spanien und Portugal Wechsel, dann stellt sich die Zeit im Handy beim Provider Wechsel auch um , das muss mit berücksichtigt werden. Bisher ist aus keiner Region der Welt ein solcher “Bugreport” gekommen. Phantomschmerz.
Hab jetzt nachgeschaut bei Waze und Gmaps.
Waze zeigt einfach lokale Zeit des Zielorts ohne Hinweise auf Zeitzonenwechsel
Gmaps macht es besser: zeigt auch die lokale Zeit des Zielorts dafür aber noch die Zeitzone am Zielort und Stundendifferenz
Beides auf nem Android device geprüft
Bei Tagestour auf Asphalt und ohne Fluxkompensator sollte sich das im Bereich +/- 1h bewegen. Den Punkt kann ich aber nachvollziehen, denke das ließe über die Art der Darstellung lösen.
ETA = local time aktuelle Position plus Differenz local time am Ziel. Ohne Angabe der Zeitzone.
In meine Fall wäre das dann
19:32 + 1
gewesen, denke das ist verständlich und macht auf den Zeitzonenwechsel aufmerksam. Es ging hier ja um die Absprache mit einen Campingplatz um sicherzustellen dass man noch rein gelassen wird. Unkritisch.
Es hätte aber auch die Abfahrtzeit einer Fähre in Klaipeda sein können, da gewinnt die Stunde schon an Bedeutung.
An der Grenze sprang die Zeit dann plötzlich um, auch irgendwie komisch.
Bringt einen alles nicht um, wenn’s leicht zu implementieren ist gern.