Revision 708: Temporal, mit Philipp Dunkel

0:00Was ist der einfache Weg? Wenn ich meine Daten richtig modele, dann sind die Outcomes auch automatisch richtig. So ein ISO-Standard, wenn sich da was tut, wenn sich da was erweitert, dann bedeutet das Millioneninvestitionen in der Industrie. Ich meine, es gibt ja immer die Frage, warum habt ihr überhaupt dieses Plain-Präfix genommen? Und da kommt es dann wieder darauf an, dass es um Entwicklerfreundlichkeit, um Lernfreundlichkeit geht. Wir wollten dem Erklärbären quasi das Leben einfacher machen.

0:55Revision 708. Wir sind heute zu dritt am Start. Da hätten wir aus dem Team einmal den Peter. Hallo Peter. Halli, hallo, hallo. Ich bin der Shep und wir haben wieder einen Gast und das ist heute der Philipp Dunkel. Hallo Philipp. Servus. Philipp, du warst noch nie bei uns und ich freue mich auch sehr, dass du da bist. Kannst du einmal kurz sagen, wer du bist und was du machst? Ah, ich bin Entwickler, API-Constructor und Mädchen für alles bei Bloomberg momentan und habe die letzten neun Jahre mit vielen, vielen, vielen anderen damit verbracht, die Welt von JavaScript durcheinanderzubringen und unter anderem Datum und Uhrzeit beizubringen.

1:44Genau, vielleicht zum Hintergrund. Bloomberg kennt man ja so als News-Firma oder Media-House, aber ihr macht eben irgendwie viel im Web und habt da hohe Ansprüche und darum ist es irgendwie passiert, dass ihr euch eben da auch engagiert. Ja, nicht gerade. Bloomberg ist eigentlich eine Technik-Company. Eine von den Großen, nur kennt man es nicht, weil es kein Customer-Produkt ist, kein Endkunden-Produkt. Das Hauptprodukt ist eigentlich eine Softwarelösung für die Finanzindustrie im Groben und Ganzen.

2:17Und die Technologie, auf der das basiert, ist alles wieder Webtechnologie. Also gar nicht so sehr, wie wir im Web unterwegs sind, das auch. Aber das ist nur die Spitze des Eisbergs. Dahinter ist noch ein Riesengewulst an Webtech-basierten Bezahlprogrammen, die die Finanzindustrie wählen. Ja, ich hatte das schon mitbekommen, das ist so mehr so Bleeding-Edge-Kram oder so, sagen wir mal, Special-Interest-Dinge, die halt nicht die Masse brauchen, aber die eben dann, also SVG, glaube ich, habt ihr auch mal.

2:53Und Hintergrundinformationen, die halt diese Menschen brauchen, ich verstehe es ja auch nicht, ich gebe ihnen nur die Information, also. Ja. Genau, bald brauchen wir keine UIs mehr, da haben wir ja KI, die haben das nicht nötig. Genau, ja. Weil Technik verstehen, ist ja vollkommen überflüssig. Wer braucht das? Das macht ja die KI. Und kurz danach atmet und lebt die auch. Meine Frau ist schon lange mit der KI weggelaufen. Und dann hören wir alle auf. Vielleicht sind wir auch alle KI, wer weiß. Ihr könnt uns ja nicht sehen, ihr Hörer. Innen.

3:35So. In Wirklichkeit mehr. Ja, der Titel gibt es ja auch schon wieder her. Also wir wollen über einen neuen API-Themenkomplex sprechen, nämlich Temporal. Anlass war, dass ich, da hatten wir auch hier im Podcast ein bisschen Werbung für gemacht, dass ich die State of the Browser-Konferenz remote per Video verfolgt habe. Und da hat dein Kollege Jason Williams einen Vortrag über Temporal API gehalten und den fand ich super, sehr interessant. Ich habe mich damit auch noch nicht so viel beschäftigt und dann sah ich irgendwann auf einem Slide einen Namen auftauchen, also seine Teamkollegen und da war ein Name dabei, wo ich dachte, ah, Moment mal, das könnte jemand sein, den man in einen deutschsprachigen Podcast wohl einladen könnte und das warst du.

4:25Genau, und so kam es, dass du hier bist. Und genau, wir wollen heute über Temporal sprechen. Genau, Jason ist, also diese Slide waren jetzt weniger Teamkollegen, weil das suggeriert, dass das alles Bloomberger waren. Das war die Liste der Champions von Temporal bei TC39. Da sind dabei Maggie Pint, damals von Microsoft, Brian Trollson, damals Microsoft, da ist Matt Johnson, da ist, also, wie gesagt, da gibt es eine ganze Liste und es lohnt sich wirklich, die alle durchzugehen, denn das sind jeden einzelne geniale Menschen.

5:05Da sind Menschen von Google dabei, da sind Menschen von, da ist Amber dabei, der das für Firefox implementiert hat, da sind Menschen über die ganze Welt verstreut und über alle Interessenssagen verspreut. Da ist Shane dabei, der macht Internationalization bei Google. Also eigentlich was ganz anderes wieder. Also eher ein Collaborate. Genialen und netten Menschen mit Fokus auf genial. Das finden wir selten. Und die eben, wie gesagt, über die letzten neun Jahre teilweise immer wieder rein und dann wieder oder dann doch wieder raus, weil neun Jahre hält ja kaum keiner durch.

5:40Und so kam eben dann Jason auch vor, naja, ich bin vor acht Jahren dazugestoßen, Jason for 6 oder so in der Größenordnung herum, um Temporal wirklich durchzubringen. Und die letzten zwei Jahre waren bei mir eigentlich mehr andere Leute treten, als selber noch was tun, während Jason über, Temporal RS, das ist die Rust-Library, die auch V8 und Boa und etliche andere jetzt verwenden, um für die Implementierung, da viel koordiniert hat, weil Jason hat ja ursprünglich auch den Boer Browser.

6:17Die Boer JavaScript Engine in Rast geschrieben, vor 100 Jahren. Und so war er jetzt quasi die letzten zwei Jahre mehr aktiv involviert und ich habe mehr Leute getreten. Und da ist dann klar, nee, Jason muss die Reden halten. Also, absollend kann er das besser und ich habe es nicht mehr in Not. Diese Revision von Working Draft wird euch präsentiert von Midwald. Next Level Container Hosting für eure Projekte. Wie euch bestimmt nicht entgangen ist, reden alle überall und ständig über Automatisierung und Self-Hosting. Und das klingt auch immer alles voll super, wenn's denn mal eingerichtet ist und läuft.

6:56Nur über diesen Schritt redet fast keiner, weil er meist kompliziert und anstrengend ist. Aber es gibt eine Ausnahme und das ist Mittfalls Container-Hosting und das funktioniert, Erster Schritt, in Mittwald's M-Studio einloggen. Ganz einfach und bequem direkt im Browser. Zweitens, fünf Minuten für die Konfiguration eures Containers aufwenden. Mehr Zeit braucht ihr nicht, denn ihr könnt die meisten Vorschläge für Entry-Points und Umgebungsvariablen einfach direkt übernehmen.

7:19Dritter Schritt, äh, euer Container läuft. Ihr seid fertig. Das war's. Von Nerds für Nerds bringt euch Mittwald das Beste, was Container-Hosting zu bieten hat. Nämlich eure Eintrittskarte ins Automatisierungs-Wunderland. Deployt ganz einfach, was ihr wollt, wie ihr wollt. Und alles dazu findet ihr auf mitwald.de slash workingdraft. Das war nochmal mitwald.de slash workingdraft. Wir danken Mitwald für die Unterstützung von dieser Revision von Working Draft.

7:50Genau, und vielleicht können wir mal starten damit. Also Temporal ist eine API, die uns den Umgang mit Daten und Zeit, Zeiträumen, Zeitmomenten und so besser gestaltet, als das bisher der Fall ist. Besser? Oder meinst du jetzt irgendwie erstmals erträglich? Eigentlich erstmals erträglich, genau. Bislang gab es dafür ja die Date-API oder das Date-Objekt. Und das gab es ja, glaube ich, schon seit JavaScript in den zehn Tagen zusammengezimmert wurde.

8:28Da gibt es ja die, da gibt es nicht, wo sie gesagt haben, wir haben nur zehn Tage, wir haben keine Zeit, was zu machen. Also klauen wir eins zu eins Java-Date, Java-YouTube-Date. Und Java hat dann ein Jahr später Java-Util-Date eliminiert, weil untauglich. Und wir haben damit noch 20 Jahre gelebt, ne? Genau, ich glaube, ich hatte irgendwie, oder vielleicht hat Jason es auch im Talk gesagt, also bei Java ist schon quasi der Nachfolger von dem Nachfolger irgendwie am Start.

8:59Und genau, in JavaScript-Land waren wir sozusagen festgenagelt auf dieses alte und auch eben in großen Teilen unzulängliche Date-Objekte festgelegt. Ich meine, in der Praxis warst du ja festgenagelt auf irgendwelche Libraries, die das wegabstrahiert haben. Genau, das war dann der nächste Schritt, um sozusagen dieses Problem dann so abzumildern, dass man eben gesagt hat, da steckt so viel drin und so viel Komplexität, lass uns das in Libraries gießen. Also da gab es ja einige von.

9:31Ja, aber der Pattern ist vor allem interessant. Weil sehr oft ist es ja so, dass quasi geh hin und designe eine API und du hast aber eigentlich keine Ahnung, was du designen willst. Du weißt zwar den Space und du bist dann für sich smart und gut, aber designe einfach mal in die Wüste rein. Und der Pattern von Temporal ist da anders, weil Maggie war eine Maintainer von Momentum. Genau, die Brücke hätte ich dann nämlich geschlagen. Ah, perfekt.

10:02Okay, na ja, gut, bauen wir doch gemeinsam eine Brücke. Und viele der Ideen, also ich habe mich lange mit Luxon beschäftigt, eben um zu schauen, was machen die? Was machen die anders? Wie schauen die APIs aus? Was brauchen wir eigentlich? Und ich glaube, der wichtigste Wurf von Temporal ist gar nicht mal, dass wir jetzt ein neues Date-Objekt haben. Also zoned date time kann eigentlich ja alles was du jetzt mal brauchst, also ist quasi das Äquivalent des neuen Date Objects, es wäre aber ein absolut dramatischer Fehler, wenn man jetzt einfach hergeht und sagt, ach okay, das kann eh alles, was ich brauche, jetzt nutze ich nur mehr das, denn der Kern Fortschritt meines Erachtens nach, ist, dass es erstmals möglich ist, Datum, Uhrzeit und dauern, so darzustellen, so abzubilden, wie sie eigentlich semantisch richtig sind.

11:03Und wenn ich das tue, dann lässt mich auch die Temporal API genau nur mehr die Dinge tun, also jetzt nicht als Restriktion, sondern im Sinne von, was ist der einfache Weg. Wenn ich das einmal richtig model, wenn ich meine Daten richtig model, dann sind die Outcomes auch automatisch richtig. Weil dann passieren mir so Dinge, wenn ich das als Plane Date, wenn ich ein Datum als Plane Date händle, ja, dann passieren mir solche Dinge wie Philipp Cimento und andere der Champions hat da einen Talk, ich glaube letztes Mal in Amsterdam bei der JS Nation gehalten, wo er erzählt, ja, er hat ein Hotel gebucht und das war dann für den falschen Tag, weil er war in Australien, die das gebucht haben und das Hotel aber nicht.

11:54Und dann ging das über die Datumsurzheitsgrenze und Date hat das über das Jahr geschoben. Das kann dir gar nicht passieren, wenn ich das als Datum melde, weil ein Datum hat keine Zeitzone. Und dann schaffst du es automatisch richtig quasi. Und das ist eigentlich der große Fortschritt. Viel mehr als nur ein neues Date-Objekt quasi. Ja. Um nochmal auf die Libraries zurückzukommen, die dann sozusagen eingesprungen sind für das unzulängliche Date-Objekt, also Moment.js, hast du ja gerade gesagt.

12:28Maggie war da Teil des Projektes, die ist dann auch als Fachfrau in den Temporal Working Group dann gejoint. Die konnte dann natürlich ihre Erfahrungswerte von der Library einbringen. Und ihr Mann Matt Thompson, war ja auch bei Moment eine Zeit lang. Dann hast du Luxon erwähnt eben, das war ja auch eine. Und dann gibt es ja noch Date Functions, das ist ja quasi die dritte Library im Bunde, oder? Gibt's noch eine? Ich glaub, die waren so die verbreitetsten, würd ich sagen, oder DateFNS.

13:01Ja, ja, ich glaub, das war's so im Großen und Ganzen, ne? Mhm. Genau, und ich glaube, die Maggie hat doch auch diese ganze Temporal-API-Geschichte dann letztlich losgetreten. Ja, genau. Das war so nach der Realisierung, ich glaube, da gibt es so eine Story, die Frage ist, ob es wahr ist, ich habe keine Ahnung. Ja, also angeblich war er auf der Jazz. Im Zug durch Europa. Also, das geht eigentlich, wir können das eigentlich nicht mehr halten, dieses ganze Momentszeug. das gehört eigentlich Kiefer vergraben im Browser.

13:39Und so kam dann der Standards-Track los. Genau, aber eben ein Aspekt, warum das in den Browser gehört, ist, dass es, selbst wenn es als Library perfekt funktioniert, sie einfach wahnsinnig groß ist. Also ich weiß nicht, wie viele? 300 Kilobyte oder was? Also alleine die Moment.js oder sowas? Genau, aber bei den 300-Kader sind noch keine Zeitzondaten dabei. Also da kommen ja dann noch die Datenpackages dabei und wenn du nicht weißt vorher, welche Zeitzone du denn brauchen wirst, weil woher, da kommt dann der Benutzer aus Afghanistan und plötzlich hast du jetzt die Zeitzone nicht da.

14:21Das kommt ja noch dazu, also da kommen dann teilweise Megabyte zusammen, Schatz, ne? Naja, und genauso wie wir die Intel API haben, um alle Themen hinsichtlich Internationalisierung, Lokalisierung irgendwie abzuwickeln, was früher auch Libraries erledigt haben, heute auch noch wahrscheinlich, gibt es eben jetzt dann Temporal, was die Erfahrung, die sozusagen die Leute, die diese Libraries gemacht haben, wie auch deren Benutzende einfließen lässt in den Webstandard.

14:54Also so paving the cow path mäßig. Genau. Genau. Und in dem Zusammenhang finde ich Intel immer so spannend, weil die Zusammenarbeit mit den Intel-Menschen, also da war sehr viel Overlapped with. ECMO 402, das ist der, 402 ist quasi die Internationalization-Gruppe. Denn, wie man ein Datum formatiert, in welchem Land, in welcher Sprache. Und es ist aber nicht nur Datum, sondern es macht ja einen Unterschied, ob das ein Datum ist, ob das eine Uhrzeit ist, ob das beides ist, ob das in der Zeitzone ist, ob das in meiner Zeitzone ist, in einer anderen Zeitzone ist.

15:40All diese Dinge sind ja in der Localization dann drinnen. Also diese Zusammenarbeit ist auch nochmal intensiv. Also nur vielleicht auch halt einer der Gründe, warum das alles so lange dauert, ne? Ja, klar. Ja, das sind halt so Aspekte, die auch Date ja überhaupt nicht abdecken konnte, wie, dass man Offset ja angeben kann zur UTC-Zeit, und damit sozusagen zwar so eine Timezone hat, aber man noch immer nicht weiß, hey, wie sieht es denn eigentlich mit Sommer- und Winterzeit aus?

16:20Wann schlägt die zu? Wann ist Sommerzeit? Wann endet die? So diese ganzen Infos sind ja nicht drin. Das heißt also auch, da kommt ja dann noch deutlich mehr dann dazu, was so quasi Lokalisierungsdaten angeht. Genau. Das ist auch einer der Gründe, warum es zum Beispiel Custom Time Zones gibt. Eine der Funktionalitäten von Temporal ist, dass du Custom Time Zones einrichten kannst, wo du als Programmierer wirklich sagst, okay, und das sind die Regeln.

16:54Das sind für so Fälle wie in, ich glaube in Marokko ist das, da wird jedes Jahr, da geht es jedes Jahr ab in die Sommerzeit. Je nachdem wann Ramadan ist, oder? Wenn es dem König zu heiß wird. Ah, okay. Für, was natürlich nicht ganz stimmt, ist nicht, wenn es dem König zu heiß wird. Ich glaube, das hat mit Ramadan zu tun. Hat mit Ramadan zu tun natürlich, aber wenn es dem König zu heiß wird, dann beschließt er, so, jetzt machen wir doch mal kurz Nicht-Sommerzeit, weil ich hätte nämlich gerne früher am Abend wieder was zu essen.

17:25Während des Ramadan. Und dann stellt das Parlament eben wie gesagt von heute auf morgen, also es geht dann ganz kurzfristig, die Zeitzone um. So kurzfristig, dass es natürlich in der Browser-Release niemals reinkommt. Und für den Fall kann man dann quasi sagen, okay, normalerweise nehmen die Zeitzone, aber, sollte quasi in der Website die Flag gesetzt sein, Achtung, jetzt ist Ramadan und die Marokkaner sind unterwegs, dann nimm doch bitte meine Custom-Times und die halt jetzt gerade wieder Winterzeit haben.

18:01Und solche Spielchen gehen dann eben, um wirklich, wirklich solide abzudämmen. Ja, da gibt es ja noch so viele andere Merkwürdigkeiten, die man irgendwie einfach nicht weiß. Also ich glaube, Brasilien, da ist der irgendwie, der nördliche Teil hat irgendwie keine Sommerzeit und der südliche Teil hat Sommerzeit. Oder das gleiche gilt auch für australische Bundesstaaten. Da gibt es ja welche, die haben das und manche nicht. Also ich glaube, um die Komplexität tatsächlich abzubilden, musst du immer sagen, gerade ist das so.

18:30Im Moment ist es halt so, dass in Brasilien das so ist und so ist und theoretisch könnte irgendein Parlament oder Diktator jederzeit sich entscheiden, das anders zu machen, weil es halt zu einem guten Punkt halt einfach arbiträr ist, wer wann, welche Zeitzone hat. Die Briten sind dafür ja bekannt. Als ich, also ich habe ja, als einer meiner ersten Taten quasi war, schreiben wir mal ein Polyfill für die damalige Version der Temporal APIs, damit man mal ein Gefühl dafür kriegt, also bevor wir quasi sagen, okay, das ist jetzt in Stein gegossen, wollten wir mal ein Gefühl dafür haben, wie kann man damit einfach umgehen, wie geht denn das programmatisch, wie funktioniert das, ist das ergonomisch quasi.

19:11Und ich teste mich verrückt an dem Ding und verstehe nicht, warum kriege ich falsche Ergebnisse für meine Zeitzonenberechnung. Naja, wo fängt der Programmierer an? In welchem Tatum, in welchem Jahr, wenn du erstmal sowas testest, wo fängst du an? Am 01.01.1970. Natürlich. Weil da hat ja bekanntlicherweise die Zeit begonnen, alles vorher ist negativ. So, das Problem ist, dass in den Jahren 70 und 71 hat Großbritannien beschlossen, den Versuch zu wagen, ohne Sommerzeit zu leben.

19:53Das heißt, wenn du genau im Jahr 1970 zufällig startest, dann geht dein Test schief. Na ja, er geht nicht schief, er passt schon, nur gab es da keine Sommerzeit. Das heißt, wenn du dann versuchst, in dem Jahr deine Sommerzeitberechnung in London zu testen, ja, viel Glück. Da gibt es etliche so Dinge. Während dem Zweiten Weltkrieg haben die Briten beschlossen, naja, wir müssen unsere Sommerzeit ändern. Wir gehen zwar auf Sommerzeit, aber dann nicht mehr zurück.

20:25Und im nächsten Jahr haben sie es nochmal gemacht, sodass am Ende des Kriegs sind sie drei Stunden früher unterwegs als sonst, um die deutsche Luftwaffe zu verwirren. Warum die geglaubt haben, dass man damit die deutsche Luftwaffe verwirrt, frag mich nicht. Aber Aber solche Perversionen gibt es auf der ganzen Welt über alle Kulturen. Also das sind nicht nur die Marokkaner und Ramana, das sind die Briten und ihre Kriege. Wie oft Amerika schon diskutiert hat, Sommerzeit ja oder nein.

20:58Da gibt es auch Arizona, wie gesagt, hat gar keine Sommerzeit. Aber alle Staaten rundherum haben Sommerzeit. Also, ja. Das ist viel zu politisch, als dass man sich da sinngemäß einreihen kann. Ähm, Und da kommen wir auch zu so Dingen wie Zeitzonenbenennung. Heißt das jetzt Kiew oder es ist Kiew? Je nachdem, auf welcher Seite ich da jetzt dieses Konflikt konkret stehe. Und da wollten wir eigentlich schauen, dass sich auf JavaScript so weit wie möglich aushält.

21:38Und darum war eine der ersten Entscheidungen, und das war auch nach wie vor eine der, also jetzt nicht nur aus dem Grund, eine der großen, wichtigen Entscheidungen ist, Wir erfinden die Welt nicht neu. Wir verwenden alle Standards, die es dazu gibt. Das bedeutet, für Zeitzonen richten wir uns genau nach dem IANA-Schema und nach sonst gar nichts. Wir erfinden jetzt nicht Systemzeitzonen wie in Microsoft Windows. IANA ist ja dieses Europe-slash-Berlin zum Beispiel, ne? Genau, genau.

22:12Wir halten uns in unseren Ausgabeformaten. Alles, was ein Sidestring ist, der nicht durch die Localization-API geht, hat ein ISO 8801-Format, also dieses klassische 4-Tage-Jahr-Strich, 2-Tage-Monat-Strich, 2-Tage-Tag und dann hinten noch eine Zeit dran. Wir halten uns einfach an alle Standards, die es da gibt, damit wir so möglichst interoperabel sind und möglichst wenig neu dazu erfinden. Weil selbst wenn man möglichst wenig neu dazu erfindet, ist die Dimension des Proposals, Immer noch die größte in der Geschichte von JavaScript.

23:01Größer noch als ES6 damals. Und ES6 haben wir alle hingefiebert von wegen Error-Functions und was nicht alles. In Sachen Tests ist Temporal größer. In Sachen Speck-Text-Länge ist Temporal größer. Ja, das war sehr eindrucksvoll im Talk von Jason. Ich glaube, da hat er die Menge Tests, die allein auf Temporal entfallen, auch mal in so einem Chart gezeigt und die verglichen mit den Tests, die man sonst für andere Dinge hat. Und es ist wirklich, also dagegen ist alles andere zusammen nix.

23:33Genau, also wir haben sehr viel Wert auf Vollständigkeit und auf wirklich solide und konservativ im Sinne von vorsichtig und progressiv im Sinne von API-weitertragend. Genau, da bleibt ja auch genug Arbeit übrig, deswegen macht es total Sinn, sich da irgendwie auf bestehende ISO-Standards zu stützen. Genau, ich glaube, der Haupt-ISO-Standard ist ja dieser 8601, der da eine Rolle spielt. Aber da hatte zumindest Jason in seinem Talk erzählt, dass ihr sozusagen beantragt habt, dass diese IANA Notation eben, die war nämlich eben nicht Teil dieser, also bis zu diesem Zeitpunkt dieser ISO Standards, dass das sozusagen als Update aufgenommen wird, dass das eben auch erlaubt wird.

24:23Und ich glaube, es ist auch so, dass Geräte, die eben noch nicht die Sianer Erweiterung kennen, glaube ich, einfach trotzdem das dann parsen können. Das ist halt das Schöne. Das ist auch nicht, dass wir erfunden haben, diese Notation. Die haben wir abgekupfert. Weil das Problem, dass man die Zeitzone als Zeitzone in ISO in 8601 nicht abbilden kann, sondern nur als Offset, ist ja nicht neu. Das haben ja andere auch, dieses Problem. Und ich bilde mir ein, ich weiß nicht mehr, wer es war.

25:02War es Oracle? Nicht unsere Erfindung quasi. Ja. Date for Java oder irgend so, wer war das? Hat das erfunden. Und wir haben nur geschaut, okay, machen wir das auch so? Weil das ist das Einzige, was es quasi im Groben und Ganzen gibt, um dieses Thema zu lösen. Oder was auch nur irgendwie standardisiert ist über die Sprachen hinweg. Und wenn Java das macht, okay, ja gut, dann Und dann gibt es zumindest Interoperabilität einer auf irgendeine Weise, weil alle anderen machen gar nichts.

25:39Dann haben wir gesagt, okay, aber wir wollen ja Standards abkupfern. Wir wollen ja nicht neu erfinden. Dann haben wir festgestellt, nee, das ist noch nirgendwo standardisiert. Das haben sie einfach gemacht. Und dann haben wir gesagt, okay, das kriegen wir nie durchs Komitee. Und insofern ist dann Utschba, es ist dann losgelaufen und hat lange mit ISO und RFC gekämpft. Um das auch in den Standard zu bringen. Und es war einer der großen Siege quasi, das in den ISO-Standard einzubringen.

26:09Und das wiederum war dann eine Voraussetzung, damit TC39 dann gesagt hat, ja, okay, könnt ihr so machen. Also es ist dann quasi die Kettenreaktion der Zeitstandards. Und das war ja so am Ende auch so das, was so mit am längsten gedauert hat, so in meiner Wahrnehmung. Dass so in der letzten Meile das noch irgendwie so durchzubringen, der Rest schien da ja schon relativ ausgewürfelt. ausgewürfelt, so habe ich es jedenfalls mitbekommen. Ja, fühlt sich so an, wenn man es einfach nur beobachtet, wenn man quasi sieht, okay, wann haben die damit angefangen, was waren die Bedingungen und was ist dann sonst noch am Standard passiert.

26:46Das war dann aber so Gen-Ende von der Stage-2-Phase. Und, Die Stage-3-Phase ist ja von außen betrachtet eigentlich kaum sichtbar. Weil da tut sich am Standard nichts mehr, also da sollte sich nicht mehr viel tun. Da wird nicht mehr groß diskutiert, machen wir es so oder so. Da wird nur mehr implementiert. Und diese gesamte Stage-3-Phase, mal angefangen mit der phänomenalen Arbeit von Amber, der das für Firefox implementiert hat, Dann die ersten Versuche von Frank, das für V8 zu machen.

27:33Frank hat das Ganze dann liegen lassen und hat andere Aufgaben gefunden sozusagen. Und dann das über Temporal RS zu implementieren. Das ist eine lange Implementierungsphase von mehreren Jahren quasi, in der von außen sichtbar jetzt gar nicht so viel passiert. Weil das passiert alles bei den Browsern. Das passiert im V8 Repository und dort wahrscheinlich im internen oder im Firefox Repository. Aber jetzt nicht sonderlich auffällig. Da gibt es nichts Neues, da gibt es keine Nachrichten.

28:16Ich finde, es gibt auch keine, jetzt in dem Sinn. Und insofern scheint es, glaube ich, mehr, als es real ist. Aber es war vor allem, Vor allem viel Warten dabei. Ja. Weil Ushwal hat absolut genial die Negotiations gehandelt und hat die alle davon überzeugt. Und dann haben die gesagt, okay, mach mal. Und dann lief das. Und dann war das auf Schiene. Und Ushwal hat nur recht regelmäßig geschaut, dass er auf Schiene bleibt. Aber das ist dann mehr so, passt eh alles.

28:56So den Blick auf die Seite. Aber das dauert einfach, bis ISO sowas losbringt. Die sind ja fast so schlimm wie TC39. Das dauert eine halbe Ewigkeit. Also da sind dazwischen schon die Dinosaurier wieder eingegangen. Gibt das irgendwie einen Grund für? Sind die irgendwie so organisationstechnisch oldschooliger drauf, weil irgendwie ältere Organisationen und irgendwie machen sowas wie ein Videocall nicht, sondern müssen sich halt irgendwie in Person treffen? Irgendwie sowas?

29:26Die sind schon modern. Also die Arbeitsstrukturen oder genauso wie modern wie alle anderen auch. Ich meine, nee, sondern das ist einfach, weil das Auswirkungen hat. So ein ISO-Standard, wenn sich da was tut, wenn sich da was erweitert, dann bedeutet das Millionen Investitionen in der Industrie, wenn Millionen genug sind. Weil dann bedeutet es plötzlich, dass jede Software auf der Welt es behaupten möchte, ISO 8601 zu unterstützen oder dass tatsächlich solche Datumstrings kriegt, müssen die jetzt alle erweitern.

30:06Das heißt, jeder von dem kleinen Schrauber in Deutschland, metaphorischer Schrauber, der seine PIM-Suite für irgendwas baut, das hat ja Konsequenz. Und darum ist man da sehr vorsichtig. Passt es eh? Wie läuft es? Können wir das hinzufügen, sodass wir dann nicht die ganze Welt zerstören? Also sprich, können die bestehenden Implementierungen, ist es eigentlich kompatibel? Was sagen eigentlich die Regeln dazu? Wie sollen diese Strings gehandelt werden, wenn man sie nicht unterstützt?

30:46Also zum Beispiel double-checken und schauen, dass die vorhergehende Spezifikation von ISO 8601 gesagt hat, ja, nach dem ersten ungewöhnlichen Buchstaben, wie zum Beispiel der eckigen Klammer, ist der Pass-Vorgang zu Ende und der Rest zu verwerfen. Das war ja der Grund, warum Java das so gemacht hat und gerade in eckigen Klammern und nicht anders, mit Abstand oder keine Ahnung was, weil eben die Pass-Regel so war, dass man sagen kann, okay. Ist nach wie vor gültiger String, hat halt mehr Info.

31:26Ja. So, und jetzt muss man schauen, ist es kompatibel? Was macht Java eigentlich wirklich? Gibt es da irgendwelche Sondersperrenzchen, die man berücksichtigen muss? Und all diese Fragen sind es, warum das bei ISO so lang dauert und im Volumen um ein Vielfaches größer, aber genau die gleiche Problematik, warum das bei TC39 so lang dauert, bei ECMA. ne? Weil neun Jahre ist ja auch nicht voll schlecht schnell, ne? Ich meine, das ist ein halbes Erwachsenenleben.

32:01Ja, sicherlich, aber ich meine, wir kriegen ja einiges dafür, ne? Also es ist ja irgendwie so im Endergebnis kann ich mich darüber jetzt auch nicht beklagen, so aus der Sicht des Nutzers, weil ich meine, sowohl, was ich jetzt alles an die Pendencies nicht mehr an der Backe habe, wie durchdacht das offensichtlich ist, wie alle Use Cases irgendwie offensichtlich abgedeckt sind, Und wie logisch das auch aufgebaut ist, da ist ja auch Qualität am Ende entstanden. Das hat sich also schon gelohnt.

32:29Da gibt es ja durchaus auch so Sachen im ECMAScript-Standard, wo ich jetzt sagen würde, die sind dann vielleicht weniger gut durchdacht. Auch neuere, aber ... Ja, genau so ist es. Also es ist natürlich, da ist viel Arbeit reingeflossen und viel Aufmerksamkeit reingeflossen und viel Detailnähe reingeflossen. Sehr oft verifiziert, dass die Designprinzipien halten und so. Und es freut mein kleines Herz, dich sagen zu hören, dass da was gelungenes drunter ist in dem Haufen.

33:07Ja, in Wirklichkeit wird es sich jetzt weisen, weil jetzt kommt es dann irgendwann hoffentlich mal in Safari, vermutlich ist mal, also Safari macht es immer dann im Eilverfahren, aber erst wenn es dann schon am Markt ist für alle anderen. Also erwarte ich mal das kommt jetzt dann auf Safari und sobald es ein Safari und insbesondere auf den Telefonen ist, dann wird die Adoptionsrate richtig in die Höhe gehen, weil dann brauche ich keine Polyphils mehr.

33:39Und dann muss es sich beweisen, weil bis jetzt hat ja noch niemand außer in irgendwelchen Samples und Experimenten irgendwas produktiv damit gemacht, was auch quasi durch die Realität getestet wird und nicht nur fürs Vergnügen. Und da wird es sich dann beweisen, ob wirklich was Sinnvolles dabei ist. Ich hoffe es natürlich sehr. Wir haben uns sehr Mühe gegeben. Aber man weiß ja nicht mehr. Also ich zweifle da doch keine Sekunde dran im Vergleich zu ... Also ich meine, jetzt sagst du auch schon irgendwie, der Safari muss das unterstützen, weil dann ist man den Polyfill los.

34:21Aber der Polyfill ist ja letztlich auch nur ein Implementierungsdetail bei denen, die es am Ende einsetzen. Ich meine, du tauschst ja im Prinzip deine Oldschool-Datums- und Zeitlibrary aus gegen das Ding, das du hinterher nur noch irgendwann mal dran denken musst zu löschen. Das ist ja schon ein relativ guter Deal, dass man den Leuten auch jetzt schon sagen kann mit dem jetzt existierenden Browser-Support, guck mal, das ist die Zukunft und wenn du das nächste Mal entweder was Neues aufgleist oder einen größeren Umbau machst, dann schmeißt doch einfach mal den alten Krempel raus, du den neuen rein, deine Use-Cases sind alle abgedeckt und für den Safari baust du das noch ein und schreibst dir halt einen Kommentar dahin, dass das halt demnächst raus kann.

34:56Also der Grund, warum ich halt glaube, dass so die Erfolgsaussichten relativ gut sind, ist halt, dass mir so als erklärbar das bisher immer relativ einfach gefallen ist, das zu verkaufen. Im Sinne von, das ist jetzt da, es ist offensichtlich erkennbar durch die API-Oberfläche, was das alles abdeckt und, dann hat man noch ein paar Beispiele und die Leute sind sofort sold und sagen sich, okay, wenn ich meinen ganzen Bestandscode nicht hätte, würde ich jetzt Moment oder hast du nicht gesehen, sofort in die Tonne treten.

35:21Das bringt mich auf eine interessante Frage, die ich euch stelle, weil ihr habt doch glaube ich mehr den Finger am Puls der breiteren Web-Öffentlichkeit sozusagen. sagen, ne? Ähm... Ein Gedanke, mit dem ich schwanger gehe quasi, ist, würde es sich lohnen oder wäre es sinnvoll, eine Moment.js API-getreue Implementierung zu machen, wo ich die Moment.js APIs auf Basis von Temporal implementiere. Also sprich, nur die API-Oberflächen transparent durch MAPE quasi und ähnliches für Date-Functions, right?

36:09Oder ist das eh mehr oder weniger lass bleiben, weil die, die das nicht selbstständig in den nächsten paar Jahren ändern, die nutzen auch sowas nicht? Ah, why not both? Also weil, ähm Ne, ich frage mich, ob sich das lohnt, das ist ja nicht both Doch, doch, doch, pass auf, pass auf, Pass auf, pass auf Du musst ja bedenken, das klingt in meinen Ohren, der ich jetzt ja von dem Zeug wirklich gar keinen Plan habe aber schon nach einem Job, der ja für unsere neuen künstlich intelligenten Overlords wie geschaffen scheint.

36:50Weil du denen im Prinzip sagen könntest, hier hast du API, so soll das sein, hier hast du schon die Test-Suite von Moment.js, die soll am Ende genauso grün werden, wie sie vorher war und jetzt mach mal, dass das sozusagen einen Unterbau hat, der temporal ist. Wie gesagt, ich mach sowas jetzt nicht, aber ich könnte mir vorstellen, dass wenn die Teile irgendwas auf die Kette kriegen, dann eine, dermaßen ausdefinierte Aufgabe und das würde ja tatsächlich den Aufwand sehr klein machen und das würde dann tatsächlich so einem lohnt sich der Aufwand.

37:15Naja, der Aufwand ist nicht existent. Warum nicht? Also ich könnte mir vorstellen, dass das, wenn du mit so Kram arbeiten willst, ein sehr billig durchzuführendes Experiment ist und ich könnte mir vorstellen, dass du damit relativ weit kommst im ersten Anlauf. Ja, also ich meine im Endeffekt ist das ja, also ich denke auch, dass dann wahrscheinlich diese Library-Maintainer dieser Libraries wahrscheinlich oder irgendwann, wie auch immer, ob KI-gestützt oder nicht, eben eine Version rausbringen, die dann im Grunde sich auf die Temporal-API stützt.

37:45Und so ein bisschen kennen wir das ja auch von Lodash, was viel so auf native Funktionen der Browser gemappt hat, was Underscore, quasi das Original, ja noch irgendwie alles selber implementiert hat. Ja, macht total Sinn. Moment ist unwahrscheinlich, dass sie es machen, weil die haben ja vor fünf Jahren oder was schon gesagt, Moment is now deprecated. Do not use this anymore. Das war ja auch der Moment, wo dann Date Functions quasi hinter dem Mistisch mal kamen oder größer wurde.

38:20Bis dahin war ja Moment der große Bär. Ja, ist halt die Frage, vielleicht müssen die das auch nicht machen, vielleicht macht es einfach irgendwer anders. Die Frage ist halt, ist der Schmerz größer, den eigenen Code an Temporal anzupassen oder ist der Schmerz größer, eben eine Moment.js-kompatible Library zu bauen, die nur durchmappt? Naja, ich komme an, wen du fragst. Wenn du mich fragst, der vorschlägt. Diese Schnittstellen-Package zu bauen, dann ist das natürlich mein Schmerz und der natürlich für mich am größten. Aber dafür ist der Schmerz für alle anderen weniger.

38:57Ja, das käme dann sicherlich von jemandem, der auch Schmerzen hat, mit zum Beispiel der Größe von Moment.js und der eben weiß, hey, hier in meinem Team, wir wissen alle gar nicht, wo wir Moment.js einsetzen. Ist es auch viel zu schwierig, das irgendwie jetzt alles zu finden und zu refactoren, aber wir können die Arbeit quasi reinstecken in so eine Library und dann wandert die sozusagen aus einem praktischen Projekt in die Öffentlichkeit. So könnte es dann passieren. Aber mal gucken, ja, wäre interessant, das zu beobachten.

39:29Wir haben ja noch gar nicht darüber gesprochen, wie Temporal sich bedienen lässt. Also wie sieht die API aus? Wollen wir das vielleicht nochmal so oder zumindest so ein paar Konzepte von Temporal mal sagen. Also wir haben zwar auch sowas gesagt wie hey, Plane Date haben wir fallen lassen, so als Stichwort und Zoned XY, aber irgendwie so die Top 3 Sachen, die an Date offensichtlich doof sind und die jetzt besser sind. Nee, wenn, dann mache ich das schon vollständig, weil es nämlich so einfach und strukturiert ist.

40:01Auf geht's, ich hab heute nichts weiter vor. Es gibt einen Kalender an unserer Wand und die quasi die Zeit im normalen täglichen Leben, wie wir sie als Normalbürger wahrnehmen. Da gibt es meine Wanduhr. Plain Time, da sehe ich nur die Uhrzeit. Da gibt es meinen Kalender am Tisch, Plain Date. Da ist nichts Zeit, das ist einfach nur das Datum. So, und dann gibt es meine Armbanduhr, auf der steht Datum und Uhrzeit, Plain Date Time. Und dann gibt es noch Feiertage, die kehren jedes Jahr wieder, so wie Weihnachten, 24.12.

40:44Das hat kein Jahr, das ist Plain Day Month. Und dann gibt es noch den, sorry, Month Day, ja. Und dann gibt es noch Year Month. Das ist quasi im Jänner 2026, wenn es länger braucht. Das sind so die Begriffe, mit denen wir als Individuen umgehen. So, und dann gibt es auf der anderen Seite die Atomuhr in Frankfurt, die rechnet eigentlich nur mit Sekunden oder genauer zu sein Nanosekunden und das ist instant, abgebildet als Nanosekunden seit dem 01.01.1970, um eben synchron zu bleiben mit der Reste der Computerei.

41:41Und dann stellt sich nur mal die Frage, wie verbinde ich die beiden? Dafür gibt es so ein Daytime. Wenn ich einem Instant eine Timezone hinzufüge, dann kriege ich Datum und Uhrzeit raus. Und umgekehrt, wenn ich hergehe und ich habe nur ein Datum und Uhrzeit, weiß aber nicht wo und ich füge eine Zeitzone hinzu, dann kann ich es am Instant festmachen. Das ist der gesamte Graph der Oberfläche. Gibt es nicht auch Duration? Operation. Ja, genau. Das ist für Unterschiede zwischen zwei von diesen Objekten auf der rechten Seite.

42:19Das können in Tagen sein, es können in Minuten sein. Dann ist es halt ein Intervall von einem Tag oder von fünf Tagen oder von fünf Minuten oder von drei Tagen und zwei Stunden. Das ist dann überkommen. Und halt eben, muss man halt eben noch rausstellen, weil wir gerade schon vom API-Design reden. Dass diese Konzepte, die du ja gerade alle aufgelistet hast, halt eben da repräsentiert sind durch halt eigene in Airquotes Klassen, also Objekte für diese ganzen Use Cases mit ihren jeweils eigenen APIs im Vergleich zu halt eben so, den Hitler-Vergleich rausholen, das Date-Objekt, ein Objekt, sie alle zu knechten.

42:55Das ist also, alles kann, aber nichts richtig. Das ist halt so, dir offensichtlich so, dass du halt einfach viele, viele Objekte hast, mit denen du jonglieren kannst und für den jeweiligen Use Case hast du das Ding, da ist die API drin, OOP at its best und deswegen relativ, sagen wir mal, offensichtlich durchdacht erscheint im Vergleich halt eben zu Date. Genau, und vom Naming her auch, ne? Also, dass diese Prefixe mit Plain und Prefix zoned, dass also klar ist, hier an diesem Datum, da hängt noch gar keine Zeitzoneninformation dran.

43:24Also das kannst du so auch gar nicht irgendwie benutzen, wenn du einen Kalendereintrag machen willst oder so. Das reicht dann nicht. Genau. Und in dem Zusammenhang, ich meine, es gibt ja immer die Frage, warum habt ihr überhaupt dieses Plane-Präfix genommen? Und da kommt es dann wieder drauf an, dass es um Entwicklerfreundlichkeit, um Lernfreundlichkeit geht. Wir wollten dem Erklärbären quasi das Leben einfacher machen. Denn in dem Moment, wo ich sage, das ist Date, Time, Date, Time, kommst du in Erklärungsnotstand, warum diese Objekte keine Zeit zonen können und warum das eigentlich nicht das Objekt ist, für was du jetzt gerade brauchst.

44:05Und insofern ist das Präfix eigentlich, also wir haben da nicht nur auf Architektonisch schön geschaut, sondern insbesondere Justin Brandt war da extrem dahinter, die Benutzerergonomie und die Discoverability und das Lernvermögen quasi einfach zu halten. Wir haben dabei schon so einen TypeScript oder VS Code Hilfe vermutet, aber damit soll eigentlich alles discoverable sein und es soll auch so sein, dass du nach Möglichkeit sofort weißt. Welche Funktion an dem Objekt du da nutzen musst, dass es eigentlich unzweideutig ist, was sinnvoll ist.

44:52Ja, so wie dieses Set-Unsafe. Es gibt ja auch dieses Set-Unsafe-HTML oder sowas. Also das sind ja auch solche Konzepte, wo quasi die Benennung schon sehr viel sozusagen darüber verrät, wie das halt funktioniert. Genau. Ja, genau. Dann ist ein Vorteil von Temporal im Gegensatz zu Date, dass es kein Mutieren von Daten gibt. Also kommt immer quasi ein Neues raus. Passieren keine ungeplanten Side Effects oder sowas. Genau, das ist ganz wichtig, weil ich sonst eigentlich aus dem Datum immer eine Zahl machen muss, um nicht mutiert zu werden und das sind in Wirklichkeit in großen Codebases, ist diese Art von Fehler genau das, was man nie findet, was dir ewig bleibt.

45:56Da passt du einmal in eine Funktion ein Datum rein und plötzlich verändert sich das Ding unbewusst, aber erst drei Monate später, weil jemand eine Addition bauen wollte und ja. Das ist bei Objekten und Erics ja auch der Fall. ist, ne? Das ist dann ganz schwierig zu debakten und zu finden, ne? Ja. Und insofern war das Key, ähm, was waren so die Prinzipien? Discoverability, Offensichtlichkeit, ähm, Immutability und Korrektheit, ne? Es gibt ja so Dinge, wo nicht unbedingt klar ist, was jetzt die richtige Antwort ist, ne?

46:38Also zum Beispiel, wir haben ja jetzt kommende Woche ab Zeitpunkt der Aufnahme, vor ein paar Wochen zum Zeitpunkt des Releases. Sommerzeitumstellung. Da verlieren wir eine Stunde, da bewegt sich dann die Zeit eine Stunde vor was, also um 2 Uhr nachts ist es plötzlich 3 Uhr. Das heißt, den Zeitraum zwischen 2 Uhr und 3 Uhr, also jetzt chronologisch gibt es ihn, aber auf der Uhr gibt es ihn nicht. So, jetzt lande ich aber, wenn ich hergehe und sage, neben 12 Uhr Mitternacht plus 2 Stunden, lande ich um 2, plus 2 Stunden 30, ja?

47:21So, da lande ich genau in der Mitte. 2 Stunden 30 gibt es jetzt nicht. Das heißt aber, dass ich jetzt dann eigentlich schon auf 3.30 Uhr muss. Das wäre korrekt. Jetzt macht es aber mal in eine andere Richtung. Der Herbst kommt, da verlieren wir eine Stunde. Um 3 Uhr ist plötzlich wieder 2 Uhr. Das heißt, 2 Uhr gibt es zweimal. Macht die gleiche Addition. Um Mitternacht plus 2,5 Stunden. Welches 2 Uhr ist denn das jetzt? Das am Anfang oder am Ende? Also das erste 2 Uhr oder das zweite 2 Uhr?

47:59Ähm, und da gibt's unterschiedliche Situationen, in der die unterschiedliche Antwort richtig ist. Ähm, und das heißt, der Default muss Saint sein, muss vernünftig sein, muss den Großteil abdecken, aber ich muss, egal was kommt, immer die richtige Antwort kriegen können. Das ist genauso wie mit Times und Parsing. Solange es strukturell richtig ist, Kann er parsen? Und semantische Fehler, also keine Ahnung, 13. Monat oder so, okay, die können wir, da kannst du mir dann sagen, wie möchtest du damit umgehen?

48:43Soll ich da sagen, okay, der 13. Monat ist der erste des nächsten Jahres? Oder möchtest du sagen, ich cap bei 12? Oder möchtest du sagen, ich throw eine Exception oder was auch immer? Also diese Art von Parsing-Fehler bei Datumsinterpretationen sind eben, da möchte ich, dass wir flexibel sind und möchte ich, dass wir alle Möglichkeiten abdecken können, solange es strukturell, also formatmäßig quasi passt. Und all diese Dinge müssen, es muss möglich sein, dass ich die richtige Antwort, die ich brauche, rechne und nicht nur irgendeine zufällige Räte wie, keine Ahnung, da 31, was ist da, der Famous, die Famous One ist vom 31.

49:29Januar plus ein Monat oder sowas. Ein Monat ist der 3. März. Genau, das würde Date ja dann verkacken, oder? Das würde Date vercutten und da gibt es, wie gesagt, unterschiedliche Modelle, wo der Default ist der 31. Jänner plus ein Monat ist der Default ist mal der 28. oder 29. Februar. Aber dann gibt es eine Flag, die sagt, nee, halte den 3. März für Date-Kompatibilität oder nee, throw eine Exception oder mach was anderes. Je nach Bedürfnis eben auch.

50:12Genau, und was wir jetzt quasi implizit auch erzählt haben, ist, dass eben viele dieser Objekte oder dieser Methoden auf dem Objekt wiederum Methoden implementieren wie Add, Substract und sowas in der Art. Oder bei Duration dann wieder andere Sachen. Genau, das ist quasi die Date and Time Math. Und gerade da ist einer von diesen Punkten, wo viele Fehler auftreten können, wo du also die Flexibilität brauchst. Entscheiden zu können, in welche Richtung deine Antwort gehen soll oder was die richtigen Regeln sind.

50:52Und das ist quasi auch die Verwendung des Duration Objects, ist eigentlich für DateNath. Das ist Abstand zwischen zwei Zeiten im Endeffekt. Genau so. Eigentlich kann man sagen, eine wirklich gut designte, relativ übersichtliche API, die aber, wo aber unglaublich viel Heavy Lifting unten drunter stattfindet und genau die auch per Default sinnvolle oder die sinnvolle Defaults hat. Aber wer dann so tiefer einsteigt in, weiß ich nicht, Localization, kulturelle Dinge, kann dann eben auch quasi anpassen und Dinge tun oder es gibt ja auch die Möglichkeit irgendwie nicht nur Jahre nach gregorianischem Kalender und nach hier Christi Orthodox oder wie das heißt zu zählen, sondern eben dann auch Ära und Jahr, also in Kulturen, wo das dann irgendwie, vorwiegend der Fall ist.

51:55Ich meine, da tut viel Heavy Lifting. Die drunterliegenden Hände, Name. Unique-Organ-Groach. Ach so. Du meinst nicht das Betriebssystem oder sowas? Ja, das Betriebssystem, da gibt's ha, jetzt ist man mal komplett blind. Die Intel Libraries verwenden es auch, die ganzen, die darunter lebende. Nicht schlimm. Ja, aber die Datenbasis ist halt, wo die Wahrheit drin wohnt. Die Datenbasis, wo eben auch die ganzen Zeitzonen und so weiter drin sind, die implementieren auch, vorgefertigte Kalender, den japanischen, den hebräischen, den arabischen, Typus A und B, so aus dem Motto.

52:44Und die machen eigentlich viel Heavy Lifting. Was Temporal macht, ist, diese Konzepte an die Oberfläche bringen und quasi aus der Versenkung holen, damit man das Richtige dann damit tun kann. Weil mit Date hat man ja gar nicht die Wahl. Und warum hat man mit Date nicht die Wahl? weil Date versucht, alles zu verstecken. Das heißt, ich bin bei solchen APIs immer ein großer Fan von möglichst transparent, möglichst durchgriffig zu sein. Gib dem User die Power, weil früher oder später, wenn du es nicht tust, dann baut er Dinge wie Moment.js, die dich sowieso umgehen, die alles, was du verhindern wolltest, dann trotzdem tun, nur sie machen es richtig hässlich und groß und unmaintainable.

53:35Und im Endeffekt musste dann das Recht Temporal werden. Und darum bin ich ein Fan von früher Transparenz für Power-User. Ja, genau. Es ist quasi so, das Leben findet einen Weg und es stellt sich raus, dass Jurassic Park eigentlich eine Dokumentation über Web-Entwicklung war. Genau, genau so. Super, ich muss leider vorschlagen, dass wir das sozusagen zu einem schönen Abschlusssatz schon deklarieren, was daran liegt, dass ich in vier Minuten leider in den nächsten Callen muss.

54:05Und ich bin auch Host, das habe ich nicht bedacht, dass ich, wenn ich rausgehen will und quasi wieder ein Videocall machen will im Anschluss, ich das hier nicht laufen lassen kann. Ja, das sollten wir jetzt dann etwa jetzt endlich mal geschafft haben, durch externe Einflüsse eine Sendung auf tatsächlich eine Stunde zu begrenzen. Es scheint so. Das ist Wahnsinn. Vielleicht dürfte er machen, ne? Ja, ich würde sagen, Philipp ist hier ein guter Einfluss.

54:32Ja, also ich fand es auf jeden Fall super, sehr cool. Auch irgendwie viel Backstory gehört nochmal und auch so ein Vorgeschmack auf die API. Wir werden natürlich das alles verlinken. Und vielen Dank für eure Arbeit und vielen Dank, dass du heute dabei warst. Ja, das war mein Vergnügen. Ja, und vielleicht in zwei Jahren nochmal, dann im kleineren Rahmen vielleicht auch, für die ganze Feedback-Runde, wie hat es denn dann geklappt? So nach dem Motto, zwei Jahre später, war es tatsächlich so benutzt?

55:06Hat es tatsächlich funktioniert oder nicht? Und wenn es schlecht läuft, haben wir dann Temporal 2 zurück in die Zukunft. Das wollen wir ja. Genau, da kommt Temporal 2 zurück in die Zukunft. Dann habe ich wieder für die nächsten zehn Jahre was zu tun, ne? So machen wir das. Das ist eine gute Idee. Vielen Dank, Philipp. Vielen Dank, Peter. Vielen Dank allen Hörenden. Wenn ihr Fragen habt, ihr wisst, wie ihr uns erreicht. Und wir werden Philipp natürlich auch verlinken, sodass ihr ihn auch anhauen könnt. Und ansonsten liken wir das gerne weiter.

55:40Nächste Woche geht's um HTTP3. Das wird auch eine spannende Folge. Genau, und bis dahin. Macht's gut, habt eine gute Woche. Und bis dann. Tschüss. Tschüssi. Ciao.