WEBVTT
00:00:00.000 --> 00:00:03.240
rc3 nowhere Vorspann
00:00:03.240 --> 00:00:05.079
Herald: Hallo und herzlich willkommen
zurück auf dem Kanal und zwar zu unserem
00:00:05.079 --> 00:00:08.440
ersten Live Talk. Unser nächster Speaker
ist Satan, er studiert Medientechnologie
00:00:08.440 --> 00:00:12.931
an der TU Illmenau und arbeitet außerdem
im Bereich Machine Learning. In seiner
00:00:12.931 --> 00:00:17.360
Freizeit beschäftigt er sich mit Assembly
Script und ist dabei auf die Zeitzonen
00:00:17.360 --> 00:00:21.380
Datenbank der IANA gestoßen. Und was er
dort gefunden hat, das erzählt uns jetzt.
00:00:21.380 --> 00:00:25.520
For English speaking viewers: There's a
translation. To listen to it in the web
00:00:25.520 --> 00:00:29.590
player select language selection and than
translated. Und jetzt Bühne frei für
00:00:29.590 --> 00:00:33.769
Satan.
00:00:33.769 --> 00:00:39.440
Satan: Danke schön. Genau. Herzlich
willkommen zu meinem Talk über eine
00:00:39.440 --> 00:00:44.630
Zeitzonen Datenbank und warum man die am
besten nicht selbst implementieren sollte.
00:00:44.630 --> 00:00:51.900
Genau. Erst mal so, was ich jetzt erzählen
werde. Erstmal so grundsätzliches so über
00:00:51.900 --> 00:00:56.881
die IANA Zeitzonen Datenbank, was es ist
und was so die Hauptaspekt sind, die da
00:00:56.881 --> 00:01:01.520
drin enthalten sind. Und dann werde ich
anhand von Beispielen und Spezialitäten,
00:01:01.520 --> 00:01:06.189
die darin enthalten sind, die
Funktionalitäten darstellen. Und am Ende
00:01:06.189 --> 00:01:09.990
kommt noch mal eine kleine Zusammenfassung
darüber, was man damit dann machen kann.
00:01:09.990 --> 00:01:14.840
Genau, also grundsätzlich ist die
Zeitzonen Datenbank, von der IANA
00:01:14.840 --> 00:01:20.610
veröffentlicht, das ist die Internet
Assigned Numbers Authority, die kümmert
00:01:20.610 --> 00:01:26.360
sich darum, um so Sachen wie DNS oder
Zeitzonen oder eben auch wie IP-Adressen.
00:01:26.360 --> 00:01:33.240
Andere Namen für die Zeitzonen Datenbank
sind auch tz, tzdb oder zoneinfo. Das
00:01:33.240 --> 00:01:35.570
kennt man aus unterschiedlichen Libraries
oder sowas. Kommen einem diese Begriffe
00:01:35.570 --> 00:01:38.880
vielleicht bekannt vor. Und die Idee
dahinter ist, dass man eine möglichst
00:01:38.880 --> 00:01:43.860
vollständige Liste aller Zeitzonen und
Regeln hinter diesen Zeitzonen und
00:01:43.860 --> 00:01:49.010
Offsets, die dadurch entstehen. Für alle
Länder weltweit und also nicht nur Länder,
00:01:49.010 --> 00:01:52.540
sondern auch Gebiete, das ist nicht
unbedingt immer geografisch
00:01:52.540 --> 00:02:04.290
[kurz fehlendes Audio] Zeit Differenzen
auszurechnen. Diese Datenbank wird ständig
00:02:04.290 --> 00:02:07.950
aktualisiert, das heißt immer wenn
irgendwo ein Gesetz veröffentlicht wird
00:02:07.950 --> 00:02:12.379
oder irgendwo irgendwelche neuen Länder
entstehen oder sonst irgendetwas passiert,
00:02:12.379 --> 00:02:19.099
was eine Änderung dafür nötig macht, wird
die geupdated und ist, dann wird dann
00:02:19.099 --> 00:02:24.749
verteilt möglichst schnell, damit alle
Systeme, die eben auf solchen, auf diesen
00:02:24.749 --> 00:02:31.069
Datenbanken basieren, möglichst schnell
upgedated werden. Auch, man könnte jetzt
00:02:31.069 --> 00:02:35.849
erwarten, dass sie irgendwie erst seit
kurzem die Daten enthält. Aber in dieser
00:02:35.849 --> 00:02:42.879
Datenbank sind eigentlich so Zeitzonen
auch für die längere Vergangenheit
00:02:42.879 --> 00:02:47.620
enthalten. Auch vor 1970 und 1972, also
zum Beispiel 1970, hat ja die Unix-Zeit
00:02:47.620 --> 00:02:54.919
begonnen und erst seit 1972 gibt es die
UTC. Das ist die Coordinated Universal
00:02:54.919 --> 00:03:00.840
Time. Genau, dann so grundsätzliches zu
der Datenbank, wie sie aufgebaut ist. Es
00:03:00.840 --> 00:03:05.069
ist eine öffentlich erreichbare Ordner mit
Dateien. Es sind einfach nur Textdateien.
00:03:05.069 --> 00:03:09.519
Es gibt z.B. über die Website kann man das
erreichen, da kann man sich tar-Archive
00:03:09.519 --> 00:03:13.769
herunterladen oder es gibt ein git-Repo in
dem man die sich runterladen kann. Es gibt
00:03:13.769 --> 00:03:17.890
auch einen FTP-Server oder ein rsync-
Server dafür, also das ist möglichst
00:03:17.890 --> 00:03:22.480
flexibel gehalten, damit sich damit ja der
Aufwand, daran zu kommen, möglichst gering
00:03:22.480 --> 00:03:27.519
ist. Das Ganze besteht aus Textdateien.
Das ist einfach. Und diese Textdateien
00:03:27.519 --> 00:03:31.599
sind nach Kontinent aufgeteilt. Zum
Beispiel gibt es eine Textdatei für
00:03:31.599 --> 00:03:38.949
Europa, eine Textdatei für Nordamerika und
so etwas. Und in dieser Textdatei sind CSV
00:03:38.949 --> 00:03:44.409
ähnliche, in dem Fall eher als CSV steht
für comma separated values. In dem Fall
00:03:44.409 --> 00:03:49.889
ist es character separated values, weil
das sind Tab separierte Tabellen, in denen
00:03:49.889 --> 00:03:54.709
eben diese Daten gespeichert werden.
Daneben sind in diesen Datei noch ganz,
00:03:54.709 --> 00:03:58.959
ganz viele Kommentare, in denen steht,
warum etwas geändert wurde, wann sich
00:03:58.959 --> 00:04:04.339
etwas geändert wurde und eben auch Links
dazu zu den Gesetzestexten und sonstigen
00:04:04.339 --> 00:04:09.069
Referenzen, die eben hilfreich sind, um
die Datenbank zu verstehen. Zusätzlich
00:04:09.069 --> 00:04:15.299
gibt es da noch in diesem Ordner noch ein
paar Scripte, mit denen man sich diese
00:04:15.299 --> 00:04:19.590
einigermaßen Menschen lesbaren Formate,
diese Tabellen in einen Maschienen
00:04:19.590 --> 00:04:26.040
lesbares Format exportieren kann, um die
auch in Libraries und sowas zu verwenden,
00:04:26.040 --> 00:04:33.700
um nicht immer den Text parsen zu müssen.
Eine der von den beiden grundsätzlichen
00:04:33.700 --> 00:04:40.131
Haupt-Datenpunkten, die enthalten sind,
sind einmal die Zonen. Die sind meistens
00:04:40.131 --> 00:04:43.410
so benannt nach einem Kontinent oder einem
Ozean und dann mit einem Schrägstrich und
00:04:43.410 --> 00:04:47.230
dann eine große Stadt, die da drin ist,
z.B. jetzt hier in diesem Fall ist jetzt
00:04:47.230 --> 00:04:56.200
ein Auszug aus der Europe-Datei und da
gibt es eben die Zone Europe/Berlin und
00:04:56.200 --> 00:05:01.060
diese Tabellen enthalten eine Liste von
Regelsatz Änderungen, das heißt, da steht
00:05:01.060 --> 00:05:06.390
sozusagen drin. Von wann bis wann muss
welcher Regelsatz angewendet werden? Was
00:05:06.390 --> 00:05:10.620
das genau ist, komme ich noch später dazu.
Und was da eben auch drinsteht ist der
00:05:10.620 --> 00:05:17.920
Base Offset. Also sozusagen für diese
Zeitzone der Offset, den alle Gebiete in
00:05:17.920 --> 00:05:23.400
dieser Zone grundsätzlich erstmal haben.
Und was es auch noch gibt, ist eben diese
00:05:23.400 --> 00:05:28.380
Format-Spalte und diese Format-Spalte ist
sozusagen der, ein Name für diese
00:05:28.380 --> 00:05:33.240
Zeitzone. Und das sind auch, seht ihr
dieses %s, aber da komme ich später noch
00:05:33.240 --> 00:05:39.930
mal genauer dazu. Das zweite sind die
Regeln. Das sind die ganzen Regelsätze und
00:05:39.930 --> 00:05:48.250
jede Zeile ist sozusagen eine Regel, wann
irgendwo sich ein Offset ändert und was da
00:05:48.250 --> 00:05:53.160
zum Beispiel auch enthalten sind. Seht ihr
die letzte Spalte, die Letter-Spalte? Da
00:05:53.160 --> 00:05:58.050
steht zum Beispiel dann ein Buchstabe
drin, der dann in diesen Namen von der
00:05:58.050 --> 00:06:03.792
Zeitzone eingefügt wird. Und zum Beispiel
ist auch eine interessante Sache an diesen
00:06:03.792 --> 00:06:07.960
Regelsätzen. Das ist für Wechsel auf
Sommerzeit und Wechsel auf Winterzeit zwei
00:06:07.960 --> 00:06:13.390
unterschiedliche Regeln gibt. Das heißt,
es kann sozusagen sich die .. der Wechsel
00:06:13.390 --> 00:06:17.920
auf die Winterzeit kann sich häufiger
ändern als der Wechsel auf die Sommerzeit.
00:06:17.920 --> 00:06:23.430
Und jetzt kommen wir zu den kleinen
Beispielen die ich euch zeigen werde, um
00:06:23.430 --> 00:06:28.520
sozusagen die Syntax und wie das Ganze
aufgebaut ist, näher zu bringen, und ab
00:06:28.520 --> 00:06:32.080
sofort werde ich auch nicht mehr den Code
anzeigen, sondern schöner formatierte
00:06:32.080 --> 00:06:37.140
Tabellen, damit es ein bisschen besser
lesbar ist. Genau das erste ist Zion, das
00:06:37.140 --> 00:06:44.670
ist das erste, ein Gebiet, und das ist das
erste, was ich gefunden habe, weil wir
00:06:44.670 --> 00:06:49.250
haben einen, ich habe einen Parser gebaut,
sozusagen, um dieses menschenlesbare
00:06:49.250 --> 00:06:54.860
Format auszulesen, und es war am Anfang
war das Pasing nur für einzelne Dateien.
00:06:54.860 --> 00:06:59.469
Und als ich dann das Pasinger mal für alle
Dateien getestet habe, ist eben an dieser
00:06:59.469 --> 00:07:05.580
Stelle der Parser fehlgeschlagen, weil
diese Syntax Fri <= 1 in der kompletten
00:07:05.580 --> 00:07:11.090
Datenbank genau einmal vorkommt. Und was
ist diese Syntax eigentlich bedeutet? Wir
00:07:11.090 --> 00:07:15.420
haben jetzt hier dieses, das "IN" und das
"ON" Feld sozusagen bestimmen, sozusagen
00:07:15.420 --> 00:07:20.610
wann diese und das "AT" Feld auch,
bestimmen, sozusagen wann dieser Übergang,
00:07:20.610 --> 00:07:26.770
also wann dieses Offset sozusagen, was in
dem Safe in der Spalte steht, angewendet
00:07:26.770 --> 00:07:32.560
wird. Und wenn da Fri <= 1 steht, bedeutet
das, dass es der erste Freitag im April
00:07:32.560 --> 00:07:38.160
ist, aber maximal der erste. Das heißt,
wenn der Freitag, der erste Freitag im
00:07:38.160 --> 00:07:42.850
April auf den zweiten oder oder bis zu den
sechsten fällt, dann nehmen wir den
00:07:42.850 --> 00:07:47.139
Freitag aus dem Vormonat. Und das ist eben
schon genau eine dieser Stellen, die dann
00:07:47.139 --> 00:07:51.020
sehr, sehr schwierig zu implementieren
ist. Wenn man dann diese Datenbank dann
00:07:51.020 --> 00:07:56.270
auch verwenden will, sozusagen, also
Libraries dafür schreiben will. Dann ein
00:07:56.270 --> 00:08:02.210
zweites Beispiel ist Lord Howe, das ist
eine Insel in Australien und dort gibt
00:08:02.210 --> 00:08:07.889
es zum Beispiel eine, die haben eine
Winterzeit, eine Sommerzeit von oder
00:08:07.889 --> 00:08:11.930
"Daylight Saving" von dreißig Minuten. Das
heißt, sie wechseln immer zwischen 0
00:08:11.930 --> 00:08:16.740
Minuten Offset und 30 Minuten Offset. Und
das sehen wir zum Beispiel diese größer
00:08:16.740 --> 00:08:20.120
gleich Syntax. Das ist eine ähnliche
Syntax mit größer gleich statt kleiner
00:08:20.120 --> 00:08:26.710
gleich. Und die besagt eben, dass es der
erste Sonntag im Monat ist, aber minimal.
00:08:26.710 --> 00:08:32.370
Der das heißt, dass es einfach immer nur
der erste Sonntag im Monat. Dann eine
00:08:32.370 --> 00:08:37.839
interessante Sache, die ich gefunden habe,
ist Kriegs und Friedenszeit. Da gibt es im
00:08:37.839 --> 00:08:47.340
US Regelsatz gibt es da zwei Regeln, also
Änderungen von den Offsets, einmal 1942
00:08:47.340 --> 00:08:57.350
und 1945, die sozusagen diesen Letter für
"W" und "P" für war und peace setzen. Und
00:08:57.350 --> 00:09:02.670
damit ist sozusagen wird an dieser
Zeitzonename gefüllt. Da komme ich auch
00:09:02.670 --> 00:09:07.001
später noch mal dazu, wie das dann in den
Zonen aussieht. Was man da zum Beispiel
00:09:07.001 --> 00:09:13.459
auch sieht ist, in der "TO" Spalte steht
ein "only" und das heißt, es wird, dieser
00:09:13.459 --> 00:09:18.769
Wechsel findet nur in genau diesem einen
Jahr statt und danach nicht mehr. Genau
00:09:18.769 --> 00:09:22.980
was man da auch sieht ist, in dem
"AT" Feld in der in der vierten Zeile ist
00:09:22.980 --> 00:09:27.870
dieses "u". Es gibt da so kleine Suffixe,
die man hinten, die da hinten dranhängen
00:09:27.870 --> 00:09:32.290
können. Da gibt es zum Beispiel "s", das
steht für Standard. Da ist dann der
00:09:32.290 --> 00:09:39.069
sozusagen, der, wird der Base Offset aus
dem ähm, aus der aus der Zone verwendet.
00:09:39.069 --> 00:09:45.529
Es gibt "g", dann wird sozusagen die Zeit
in Greenwich Mean Time verwendet, "u" für
00:09:45.529 --> 00:09:50.149
UTC, was jetzt in dem Fall der Fall ist,
für wieder coordinated universal time oder
00:09:50.149 --> 00:09:54.120
was zum Beispiel auch da stehen kann. Was
auch der Standard ist, ist "w" das heißt
00:09:54.120 --> 00:09:58.660
"wall" für "wall clock" und das heißt, es
ist die Uhrzeit, die es an der Stelle zu
00:09:58.660 --> 00:10:02.800
dem Zeitpunkt auch wirklich hätte, also
die man an der Stelle von der Uhr ablesen
00:10:02.800 --> 00:10:09.089
würde. Und da hat es aber der Default, das
wird dann meistens weggelassen. Dann so
00:10:09.089 --> 00:10:15.369
wie Sommer und Winterzeit funktioniert. Es
gibt, wie vorhin schon erwähnt, getrennte
00:10:15.369 --> 00:10:19.410
Zeilen für Wechsel auf Sommerzeit und
Wechsel auf Winterzeit. Und das sieht man
00:10:19.410 --> 00:10:25.579
jetzt hier an dem US Beispiel auch ganz
schön, dass sie ihre.. den Wechsel auf
00:10:25.579 --> 00:10:31.649
Daylight Saving Time deutlich häufiger
geändert haben als auf Summertime. Was man
00:10:31.649 --> 00:10:35.990
jetzt auch hier zum Beispiel sieht, ist in
dem "TO" Feld ein "max". Und dieses "max"
00:10:35.990 --> 00:10:39.100
bedeutet sozusagen bis in die Gegenwart.
Implementiert ist das in manchen
00:10:39.100 --> 00:10:41.730
Implementationen das an der Stelle einfach
der maximal integer genommen wird. Und
00:10:41.730 --> 00:10:47.179
dann ist das irgendein Jahr ganz weit in
der Zukunft. Und das ist aber immer
00:10:47.179 --> 00:10:54.430
sozusagen bis aktuell zur Gegenwart, was
das auch aktuell ist. Dann habe ich noch
00:10:54.430 --> 00:10:58.959
Hawaii mitgebracht. Dort sieht man zum
Beispiel, das ist jetzt eine Zone bei der
00:10:58.959 --> 00:11:04.309
Zone sieht man, das in der erst in den
ersten zwei Spalten, die Zeilen nicht
00:11:04.309 --> 00:11:08.789
wiederholt werden. Das liegt daran, dass
sozusagen die Zone sich immer, auf die
00:11:08.789 --> 00:11:14.170
gleiche Zone bezieht. Deswegen wird es
dann weggelassen. Und was man dort auch
00:11:14.170 --> 00:11:18.319
sieht ist, das Format steht "LMT", also
Abkürzung. Das ist dann die Abkürzung für
00:11:18.319 --> 00:11:25.660
die Zeitzone, in der Format-Spalte und
"LMT" steht für Local Mean Time und ist
00:11:25.660 --> 00:11:29.360
eigentlich gar kein richtiger Zeitzonen
Name, wird aber innerhalb der Datenbank
00:11:29.360 --> 00:11:34.329
immer verwendet, wenn es zu dem Zeitpunkt
keinen richtigen Namen dafür gibt, weil
00:11:34.329 --> 00:11:38.019
nichts veröffentlicht ist oder sonst
irgendetwas. Das sieht man auch, das es,
00:11:38.019 --> 00:11:42.369
dieser Name geht sozusagen bis 1896. Das
heißt, das ist schon eine ganze Weile her,
00:11:42.369 --> 00:11:48.079
bevor man überhaupt so viel mit Zeitzonen,
so was sich Gedanken gemacht hat. Was man
00:11:48.079 --> 00:11:54.720
auch hier an dem Hawaii Beispiel sieht,
ist dieses "%s" in der vierten Zeile im
00:11:54.720 --> 00:11:58.721
Format. Und an dieser Stelle wird dann so,
wird dann der Buchstabe, der in der Regel
00:11:58.721 --> 00:12:05.070
festgelegt wird, eingesetzt. Da muss eine
Sache, die man da beachten muss, ist, dass
00:12:05.070 --> 00:12:09.559
das führt. Damit das funktioniert, muss
für diesen Zeitpunkt oder für diesen
00:12:09.559 --> 00:12:14.189
Bereich auch ein Regelsatz gelten, weil
zum Beispiel, wenn er jetzt ein Minus oder
00:12:14.189 --> 00:12:18.600
eine einfache Zahl steht, dann gilt da
kein Regelsatz. Und dadurch ist natürlich
00:12:18.600 --> 00:12:22.160
auch kein Buchstabe dafür definiert. Was
man jetzt genau ich auch gerade schon
00:12:22.160 --> 00:12:25.190
erwähnt hatte, ist das auch eine Zahl
stehen kann in "RULES", in "RULES" stehen
00:12:25.190 --> 00:12:29.040
sozusagen welcher Regelsatz gerade
angewendet wird. Wenn ein Minus steht,
00:12:29.040 --> 00:12:32.999
gibt es einfach kein Regelsatz, dann geht
es einfach nur der Standard-Offset. Wenn
00:12:32.999 --> 00:12:37.629
da eine einfache Zahl steht, also eine
Stunden und Minuten Zahl, dann ist das
00:12:37.629 --> 00:12:43.860
sozusagen der Offset. Und wenn ein, eine
Buchstabenkombination da steht, dann ist
00:12:43.860 --> 00:12:51.759
das das Regelsätze auf der zu dem
Zeitpunkt gilt. Genau dann habe ich noch
00:12:51.759 --> 00:12:59.430
Alaska. Alaska wurde 1867 von Russland an
die USA verkauft und dadurch haben sie
00:12:59.430 --> 00:13:11.029
ihren Offset von +15h auf -9h, also
ungefähr gewechselt, um sozusagen einmal
00:13:11.029 --> 00:13:15.459
auf die andere Seite der der Datumsgrenze
zu gehen. Und was daran auch interessant
00:13:15.459 --> 00:13:21.819
ist, ist das, dass dieser Tag sozusagen
doppelt stattgefunden hat, weil es
00:13:21.819 --> 00:13:31.410
sozusagen um 15:33 Uhr, dann im Jahr 1867
haben sie um 24 Stunden zurückgesetzt die
00:13:31.410 --> 00:13:38.550
Uhrzeit und dann hat der Tag sozusagen
noch mal stattgefunden. Jetzt noch mal
00:13:38.550 --> 00:13:42.699
eine kleine Zusammenfassung, wie das alles
gemeinsam funktioniert. Wir gucken jetzt
00:13:42.699 --> 00:13:48.029
die Zeitzone und den Regelsatz an, der
aktuell bei uns gilt. Wir haben jetzt hier
00:13:48.029 --> 00:13:52.619
die Zone Europe/Berlin. Das ist für
Deutschland die Zone, die verwendet wird.
00:13:52.619 --> 00:13:57.809
Und wir sehen, dass der vorletzte Eintrag
bis 1980 gilt. Das heißt, wir sind darüber
00:13:57.809 --> 00:14:04.069
hinaus. Und wenn das "UNTIL" Feld leer
ist, heißt es einfach bis jetzt. Und da
00:14:04.069 --> 00:14:08.741
sehen wir, wir haben einen Standard-Offset
von einer Stunde und der Regelsatz, der
00:14:08.741 --> 00:14:14.199
gerade gilt, ist "EU" und das Format, also
der Name ist "CE" und dann der Platzhalter
00:14:14.199 --> 00:14:21.170
und ein großes T. Jetzt schauen wir uns
den EU Regelsatz also an, der aktuell
00:14:21.170 --> 00:14:25.910
gilt. Da haben wir seit 1981 und 1996
gelten eben diese beiden Regeln, um in
00:14:25.910 --> 00:14:33.810
Sommerzeit oder Winterzeit zu wechseln und
zwischen Oktober und März gilt die untere
00:14:33.810 --> 00:14:40.139
Regel. Also wir haben sozusagen im Oktober
haben wir die untere Regel angewendet, um
00:14:40.139 --> 00:14:44.639
den Safe, also den zusätzlichen Offset auf
Null zu setzen, das heißt, wir haben einen
00:14:44.639 --> 00:14:49.499
Standard-Offset von eins plus unserem Safe
von Null. Das heißt, wir sind aktuell bei
00:14:49.499 --> 00:14:55.050
einem gesamten Offset von UTC von Null.
Und jetzt können wir uns noch den Letter
00:14:55.050 --> 00:14:59.170
angucken, da es aktuell ist, ist da ein
Strich, das heißt einfach nichts. Und wenn
00:14:59.170 --> 00:15:04.149
wir das jetzt in das Template einsetzen,
steht da CET und das ist Central European
00:15:04.149 --> 00:15:08.470
Time. Und wenn wir jetzt sozusagen in der
Sommerzeit wären, würde da ein "S" drin
00:15:08.470 --> 00:15:13.989
stehen und dann hätten wir Central
European Summertime. Genau das wäre es
00:15:13.989 --> 00:15:18.339
jetzt auch so von meiner Seite aus. Ich
danke euch vielmals für eure
00:15:18.339 --> 00:15:24.230
Aufmerksamkeit und wünsche euch gestern
noch viel Spaß auf dem Rest vom Kongress.
00:15:24.230 --> 00:15:28.959
Genau, wenn ihr jetzt.. ich habe noch ein
paar Links. Wenn ihr noch Fragen habt,
00:15:28.959 --> 00:15:33.280
dann könnt ihr mir per Mastodon schreiben.
Und noch einen Link zur Zeitzonen
00:15:33.280 --> 00:15:35.340
Datenbank.
00:15:35.340 --> 00:15:38.480
Herald: Genau. Vielen Dank Satan..
Satan: Dankeschön.
00:15:38.480 --> 00:15:41.860
Herald: .. für den interessanten Talk.
Genau. Im Anschluss an den Talk wird es
00:15:41.860 --> 00:15:44.970
eine kleine Breakout Session geben und
Satan wird da auch noch mal zur Verfügung
00:15:44.970 --> 00:15:49.559
stehen. Das passiert in der rc3 World im
FEM Office. Das müsste jetzt auch noch
00:15:49.559 --> 00:15:54.180
eingeblendet werden. Genau perfekt. Und
hier auf dem FEM-Kanal wird es jetzt dann
00:15:54.180 --> 00:15:58.639
um 19 Uhr mit der nächsten Herald Newsshow
weitergehen und um 20:15 Uhr mit dem
00:15:58.639 --> 00:16:02.649
nächsten Talk zu Grundlagen der Video
Kompression. Bis dahin und vielleicht bis
00:16:02.649 --> 00:16:05.948
gleich.
00:16:05.948 --> 00:16:08.418
rc3 nowhere Abspann
00:16:08.418 --> 00:16:30.000
Untertitel erstellt von c3subtitles.de
im Jahr 2022. Mach mit und hilf uns!