Der Umgang mit Datum und Zeit ist schwierig
by Volker Weber
Es gibt kaum ein IT-Problem, was so einfach zu sein scheint wie ein Kalendar und doch gleichzeitig höllisch schwierig ist. Wie schwer kann es sein, die an einem Tag gemessenen sportlichen Aktivitäten zusammenzuzählen und übersichtlich darzustellen? Es ist offensichtlich so schwierig, dass Apple das einfach nicht gebacken bekommt. Oder glaubt jemand, dass ich meine Apple Watch am 12. Mai nur einmal kurz eingeschaltet habe, am 14. gar nicht, und dazwischen am 13. nur ein ganz kleines bisschen?
Gerade fliegen in Australien die neuen Apple Uhren aus der Kurve, wenn sie auf dem brandneuen Infograph-Zifferblatt eine Komplikation haben, die diese Daten versucht anzuzeigen. Warum gerade jetzt? Weil in Australien die Sommerzeit begonnen hat und ein Tag nur 23 Stunden hatte. Ich glaube ernsthaft, dass Apple in diesem Bereich der Software-Entwicklung ein paar Leute austauschen muss.
Comments
Oh, ja.
Doppelt schwierig wird es dann für mich als #dontbreakthechain'ler bei Zeitzonenwechseln. Die Trainings-Zeiten scheinen zeitzonensensitiv zu sein. Ich überleg immer - Was muss ich machen, damit ich bei einem Flug nach Asien oder von da zurück nicht einen Tag verliere oder überspringe? Muss ich vor dem Flug schon meine Ringe vollmachen, dann danach auch wieder? Thailand. 14 Stunden Flug, 6 Stunden Zeitverschiebung.
Letztes Mal hab ich mich mit dem Umstellen der Zeitzone noch etwas geziert. Vorletztes Mal hatte ich meine Zeitzone am Anfang des Fluges umgestellt und prompt fehlte mir ein halber Tag. Die Exercise aus der Überlappung wurde auf den neuen Tag gebucht. Der Tag, an dem ich eigentlich die Aktivität hatte, war halb leer.
Mir leuchtet nicht ein, wieso das zeitzonenabhängig realisiert ist. Wenn ich rumhopse und Aktivität habe, und logisch ist es der xx.yy., dann buch die Aktivität auf den xx.yy. Wenn ich dann die Uhr umstelle und es ist der xx+1.yy., dann hab ich aber immer noch am xx.yy. das erforderliche Maß rumgehopst.
Naja. First World Problems....
Du machst am Montag, den 8. Oktober in Berlin Sport, fliegst am Nachmittag nach New York (-6 h glaube ich) und läßt Dich vom Taxi direkt zum Central Park bringen, wo Du - fight the jetlag - ein paar Runden drehst. In New York ist noch der 8., zu Hause inzwischen der 9. Oktober. Danach fällst Du in einen komatösen Schlaf. Wo soll Deine Aktivität gebucht werden?
Martin: Es würde schon helfen, wenn man wüsste, wie es sich verhält. Ich hatte auch schon meinen Tag voll (zumindest hat es die Uhr und das Telefon gesagt) - aber dummerweise waren es nach der Zeitumstellung plötzlich ein paar Kalorien zuwenig für den "Vortag". Hat mich damals wirklich geärgert, da man das ja nicht rückgängig machen kann. Aber heutzutage ist dann halt der Tag nicht voll und die Erde dreht sich trotzdem weiter :)
Wir müssen einfach warten bis @_inside ein Tool ausgetüftelt hat, um das SQLite-Backing für die CoreData-Modelle zu editieren. :-)
Martin - siehe meinen letzten Punkt. Alles auf den 8.
So lange da, wo ich rumsporte, der 8. ist, alles auf den 8. "zu Hause" ist für meine Aktivität ein völlig irelevantes Konzept.
Es ist ein Kraus wie das Datum und die Zeit in der Softwareentwicklung behandelt werden. Dabei gibt es in nahezu jeder Programmiersprache brauchbare Bibliotheken und trotzdem wird es immer wieder per Hand probiert. Besonders fehleranfällig sind Berechnungen.
Für den Interessierten eine Seite mit den Unmengen an Fallstricken bei Datum und Zeit http://yourcalendricalfallacyis.com/
Au weia. Ist ja noch schlimmer als ich dachte.
@Max da fehlt sogar noch was:
Freitag um eins macht jeder seins.
Mostly true :)
Wer bei einfacher Uebung zu sehr auf die Messtechnolgie aufpasst hat vergessen, was wichtig ist.
Ich schätze mal die erfassen zum Zeitpunkt der Aktivität das aktuelle Datum. Ist ein wenig doof mit Zeitverschiebung... würden Sie das Datum einfach zum Zeitpunkt der Anzeige neu berechnen wäre das alles kein Problem; ausser, dass dann deine Ringe in Australien anders aussehen würden als in Deutschland... Konsistent ist das dann leider auch nicht, wenn auch ein wenig besser.
Das gleiche Problem ist jedes Mal mit Geburtstagsbenachrichtigungen die dann bei Zeitverschiebung am falschen Tag kommen; manchmal aber richtig; weiss man vorher nie so genau. Für Leute mit schlechtem Gedächtnis nicht optimal ;-)
für mich hört sich das so an, als ob das einzig sinnvolle die Erfassung in der Zeitzone "UTC" wäre (bzw eine Rückrechnung von der eingestellten Zeitzone auf UTC bei Erfassung).
Wie Gerhard dann schon sagt, die Ringe würden dann in Australien, USA, Deutschland etc jeweils anders aussehen und nicht konsistent sein, aber die Erfassung wäre zumindest konsistent und logisch.
Um dann an die "richtige" Anzeige zu kommen, müsste m. E. die App selbst eine abweichende Anzeigeoption mit "Anzeigezeitzone" bereitstellen. Oder evtl sogar eine zweite und/oder dritte… 1 x die "heimatzeitzone" + 1 x die aktuell eingestellte Zeitzone und/oder eben die Anzeige in UTC.
Auf UTC zu normalisieren würde dazu führen, daß Dein "Tag" komisch aussieht, wenn Du die Zeitzone wechselst.
@Daniel: Wenn Du im obigen Beispiel alles auf den 8. buchst, hat Dein "8." mehr als 24 Stunden. Zu Lasten des Tages danach... Und ich habe noch nicht mal vermutet, daß Du im Flugzeug zählbare Gymnastik machst. :-)
Zeitzonen- und DST-Mathematik sind gut durch Frameworks beschrieben, widersetzen sich allerdings oft der Nutzererwartung.
http://yourcalendricalfallacyis.com/
Harhar, bei euch musste ich an ein Paper aus der minkorrekt Podcast Folge 121 denken: "I track, Therefore I walk": https://www.sciencedirect.com/science/article/pii/S1071581918301915?via%3Dihub
Habt ihr euch wirklich bewegt, wenn der Tracker es nicht aufgezeichnet hat? ;-)
"Auf UTC zu normalisieren würde dazu führen, daß Dein "Tag" komisch aussieht, wenn Du die Zeitzone wechselst.“
Das verstehe ich nicht. Wenn ich bei der Erfassung alles auf UTC+-0 normalisieren würde, wäre ich doch zeitzonenunabhängig, oder nicht?
Meine in Deutschland erfassten Kreise sähen dann zwar in der amerikanischen Zeitzone eventuell anders aus, aber das macht die Tage ja trotzdem nicht != 24h lang.
Wo ist mein Denkfehler?
Leute denken nicht in UTC. Du kannst die Daten in UTC erfassen, aber Du musst sie dem Nutzer so präsentieren, wie er Tage erlebt.
Mh, mir gings um die Erfassung.
Wenn ich es richtig verstanden habe, wird aktuell die zur aktuellen Zeitzone passende Uhrzeit erfasst. Das führt unter Umständen zu Fehlern, wenn man die Zeitzone wechselt. Verstehe ich.
Aber wenn ich Zeitzonen-unabhängig erfasse, ist ja erstmal jede Zeit korrekt erfasst. Oder nicht?
Wenn ich dann für die Anzeige die eingestellte Zeitzone verwende, werden mir zwar die in einer anderen Zeitzone erfassten Daten u.U. seltsam angezeigt, aber generell sollten die Tage doch trotzdem nicht länger oder kürzer als 24h sein. Also korrekt, wenngleich mitunter seltsam.
Das Achievement-System würde natürlich trotzdem nicht perfekt laufen und wir mögen Achievements eben. Es stört wenigstens das Auge, wenn wir um einen Erfolg wissen, aber das System ihn uns verweigert.
Dazu müsste man dann wohl einzelne Tage Zeitzonen zuordnen können müssen. Oder sogar einzelne Trainingseinträge.
