Explizites Tracking der Start/Ende-Zeiten für Termine

[penguineer]

Für ical-Events benötigen wir formale Start-/Ende-Zeiten, d.h. die Daten sollten um entsprechende Felder erweitert werden, anstatt hier Freitext-Angaben vorzusehen.

[penguineer]

Mir allen ad-hoc zwei Lösungen ein:

1. Explizite Angabe von Start und Ende: Das entspricht den Daten, die wir im Ical wahrscheinlich brauchen, aber dann müssten wir validieren, ob die Angaben sinnvoll sind.
2. Angabe von Start-Zeit und Dauer, was die Validierung vereinfacht. Eventuell kann ical auch mit der Dauer eines Termins arbeiten.

Außerdem ist es sinnvoll, ganztägige Termine vorzusehen.

[penguineer]

Das Problem existiert parallel in JensWinter/tech-events-magdeburg#70

[timherrm]

Wenn wir jetzt Start/Dauer hinzufügen, müssen wir jedes der neuen Events manuell anpassen, oder? Wäre ggf. besser gewesen, erstmal die Struktur des Events festzulegen.

Das ist mit dem Script, welches jetzt unter "tools" liegt, dann kein Problem. Das Format da einmal eintragen, drüber rattern lassen und gut ist, also zum Glück nichts mit händisch anpassen.

Eine andere Sache die mir heute noch eingefallen ist: Ich hätte zB gerne einen mehrtägigen Termin eingetragen. Stand jetzt weiß ich gar nicht ob/wie das geht. Das wäre ja dann mit Start/Ende bzw. Start/Dauer auch erledigt.

[timherrm]

Das steht in einer ICS drin, die auf unsere Zeitzone angepasst ist:

CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Europe/Berlin
LAST-MODIFIED:20230407T050750Z
TZURL:https://www.tzurl.org/zoneinfo-outlook/Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE

Und dann sehen die Events so aus:

BEGIN:VEVENT
UID:20231108@netz39.de
ORGANIZER;CN="Netz39 Team":MAILTO:kontakt@netz39.de
LOCATION:Netz39 e.V.\, Leibnizstraße 32\, 39104 Magdeburg
SUMMARY:Netz39-Stammtisch
DESCRIPTION:More info at https://www.netz39.de/events/2023/2023-11-08_n39_stammtisch
CLASS:PUBLIC
DTSTART;TZID=Europe/Berlin:20231108T193000
DTEND;TZID=Europe/Berlin:20231108T210000
DTSTAMP:20231107T104422Z
END:VEVENT

[24367dfa]

Mir allen ad-hoc zwei Lösungen ein:

1. Explizite Angabe von Start und Ende: Das entspricht den Daten, die wir im Ical wahrscheinlich brauchen, aber dann müssten wir validieren, ob die Angaben sinnvoll sind.

2. Angabe von Start-Zeit und Dauer, was die Validierung vereinfacht. Eventuell kann ical auch mit der Dauer eines Termins arbeiten.

Außerdem ist es sinnvoll, ganztägige Termine vorzusehen.

Ich bin dafür, Start- und Endzeit als vollständiges Datum/Uhrzeit tupel direkt in die Metadaten einzutragen und beim Templaten auseinander zu nehmen.

[penguineer]

Ich bin dafür, Start- und Endzeit als vollständiges Datum/Uhrzeit tupel direkt in die Metadaten einzutragen und beim Templaten auseinander zu nehmen.

Der Nachteil an der Methode ist, dass die Validierung wesentlich aufwändiger ist. Startzeit + Dauer ist immer ein gültiger Termin, aber jemand™ könnte den Endzeitpunkt vor die Startzeit legen.

[24367dfa]

Fair Point. Für Ganztagesevent dann start0:00 mit 24h Dauer?

[penguineer]

Für Ganztagesevent dann start0:00 mit 24h Dauer?

AFAIK wird das im ICAL anders gekennzeichnet und hätte dann bei uns auch ein entsprechendes Attribut - da müssten wir mal in die ICAL-Details schauen.

[24367dfa]

Dann kommen wir aber von dem schönen einfachen Jekyll template für den Feed weg.

[penguineer]

Ja, aber dafür ist es ja ein Jekyll-Template. Wir schreiben einmal ein Layout, das aus einem Event ein ICS macht und binden das überall ein, wo wir es brauchen.

[penguineer]

Eine Event-Definition kann dann so aussehen:

---
layout: event
title:  "Stammtisch KW42"
event:
  date:   2023-10-18
  duration: P1H30M
#  allday: false
  venue: Netz39 e.V., Leibnizstr. 32, 39104 Magdeburg
#  online: 
  url: https://wiki.netz39.de/stammtisch:2023:2023-11-08
---

Heute ist Stammtisch!

Der Markdown-Content würde dann in der Description auftauchen.

Alternativ kann man duration: allday angeben und den Sonderfall auswerten.

[penguineer]

Die Angabe als Markdown mit Layout hat den Vorteil, dass man das einfach als Page anzeigen lassen kann und mit dem Content viel Raum für Beschreibung hat. Der Nachteil ist, dass die Seite genau diese Page wird und sich nicht so leicht woanders verarbeiten lässt. Alternativ gibt man es als YAML-Collection an (dann liegen die Events z.B. unter _data/events) und erstellt die entsprechenden Seiten (Markdown/Jekyll) per Templates. Das hängt auch davon ab, was wir alles mit den Terminen machen.