Der Umgang mit Datum und Zeit ist schwierig

by Volker Weber

ZZ53B392D3

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....

Daniel Tietze, 2018-10-08

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 Kautz, 2018-10-08

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 :)

Bernd Schuster, 2018-10-08

Wir müssen einfach warten bis @_inside ein Tool ausgetüftelt hat, um das SQLite-Backing für die CoreData-Modelle zu editieren. :-)

Martin Kautz, 2018-10-08

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.

Daniel Tietze, 2018-10-08

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/

Max Bauer, 2018-10-08

Au weia. Ist ja noch schlimmer als ich dachte.

Volker Weber, 2018-10-08

@Max da fehlt sogar noch was:

Freitag um eins macht jeder seins.
Mostly true :)

Stephan Herz, 2018-10-08

Wer bei einfacher Uebung zu sehr auf die Messtechnolgie aufpasst hat vergessen, was wichtig ist.

Michael Rohrbach, 2018-10-09

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 ;-)

Gerhard Poul, 2018-10-09

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.

Matthias Michl, 2018-10-09

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/

Martin Kautz, 2018-10-09

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? ;-)

Ralf ter Veer, 2018-10-09

"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?

Nina Wittich, 2018-10-09

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.

Volker Weber, 2018-10-09

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.

Nina Wittich, 2018-10-10

Post a comment

Store next two fields in a cookie for you?




Use your full name and a working email address. Unless you want your comment to be removed. No kidding.

Recent comments

Tobias Hauser on New Apple Watch complications at 14:16
Volker Weber on Apple Watch Activity Competition revisited #dontbreakthechain at 11:48
Ralph Inselsbacher on Apple Watch Activity Competition revisited #dontbreakthechain at 11:48
Nina Wittich on New Apple Watch complications at 11:43
Felix Kluge on iPhone drahtlos laden at 10:44
Volker Weber on iPhone drahtlos laden at 09:23
Frank Köhler on iPhone drahtlos laden at 08:59
Ingo Harpel on iPhone drahtlos laden at 07:47
Bernd Ries on Apple Watch Activity Competition revisited #dontbreakthechain at 05:02
Volker Weber on iPhone drahtlos laden at 23:24
Christian Hirth on iPhone drahtlos laden at 23:19
Volker Weber on iPhone drahtlos laden at 20:05
Stefan Dorscht on iPhone drahtlos laden at 19:42
Alexander Kluge on iPhone drahtlos laden at 19:24
Marc Henkel on Apple Watch Activity Competition revisited #dontbreakthechain at 11:48
Volker Weber on Android Enterprise Security Whitepaper at 11:16
Goetz Herzog on Just a silly wishlist for the next Macbook at 11:08
John Keys on Demnächst in diesem Theater :: Surface Go at 23:40
Johannes Koch on Android Enterprise Security Whitepaper at 22:05
Patric Stiffel on Demnächst in diesem Theater :: Surface Go at 22:00
Andy Mell on Just a silly wishlist for the next Macbook at 19:08
Klaus Iwik on Just a silly wishlist for the next Macbook at 19:06
Jörg Michael on Just a silly wishlist for the next Macbook at 18:52
John Curtis on #dominoforever :: Observations from the event at 18:12
Volker Weber on Just a silly wishlist for the next Macbook at 17:57

Ceci n'est pas un blog

I explain difficult concepts in simple ways. For free, and for money. Clue procurement and bullshit detection.

vowe

Contact
Publications
Stuff that works
Amazon Wish List
Frequently Asked Questions

rss feed  twitter  amazon

Local time is 14:21

visitors.gif

buy me coffee