search

lotta-schule / lotta

Lotta Web Monorepo
https://lotta.schule
GNU Affero General Public License v3.0
4 stars 0 forks source link

Kalenderabo: Zeitzone wird bei Konvertierung von DateTime zu Date nicht beachtet #399

Closed wie0815 closed 3 weeks ago

wie0815 commented 3 weeks ago

Bug-Beschreibung

Kalendereinträge werden in der Marginalen korrekt dargestellt. Bsp.: Klausuren 11er am 28.10.2024 KU1 (Nr.1). Im Abonnement erscheint der Termin am 27.10.2024 (also an einem Sonntag!). Der Fehler betrifft alle Einzeltermine. Vgl. Marginale "Klausuren"

Link zur Seite, auf der das Problem aufgefallen ist

https://ehrenberg-gymnasium.de

Gerätekategorie

Trifft hier nicht zu

In welchem Browser ist das Problem aufgetreten

No response

ptitmouton commented 3 weeks ago

Problem ist dass die Zeitzone des Termins wird nicht korrekt beachtet.

Alle Daten sind bei uns intern in der Datenbank erstmal als "DateTime" (Datum mit Uhrzeit) gespeichert. Bei ganztägigen Ereignissen geben wir aber nur das ical-Format "Date" (ohne Zeit) aus (Format YYYYMMDD). Dafür wandeln wir zu ISO8601 um, nehmen die "-" weg und schneiden alles nach dem T weg.

Also (in dem Fall KU1 Start): → 28. Oktober 2024 00:00 in Central European Standard Time → 2024-10-28T00:00:00+01:00 → 2024-10-27T23:00:00Z → 20241027

Das Problem ist also dass DateTime.to_iso8601/1 grundsätzlich in UTC umwandelt.

ptitmouton commented 3 weeks ago

Die Umwandlung zu UTC passiert in dem Fall tatsächlich weil postgres anscheinend nur UTC speichern kann. Lösung wird sein die Zeitzone des Ereignisses zusätzlich zu speichern.

Da wird quasi ausschließlich mit CEST zu tun haben, denke ich brauchen wir das erstmal nicht in der Oberfläche anzuzeigen / änderbar machen.

wie0815 commented 3 weeks ago

Was heißt das nun? In der Google-Kalender-App ist der Fehler immer noch sichtbar. D.h. dass z.B. der Termin Klausur KU1 am Montag den 28.10. am Sonntag den 27.10. angezeigt wird.

ptitmouton commented 3 weeks ago

Ja tatsächlich scheint Google bei mir auch noch die falschen Daten anzuzeigen.

Das Problem ist aber gelöst:

> curl 'https://ehrenberg-gymnasium.de/data/calendar/<vertraulich>/ics'
[...]
BEGIN:VCALENDAR
VERSION:2.0
METHOD:PUBLISH
CALSCALE:GREGORIAN
REFRESH-INTERVAL;VALUE=DURATION:PT6H
PRODID:-//einsa Gbr//Lotta//DE
X-WR-CALNAME:11er
NAME:11er
COLOR:#f5af16
DTSTAMP:20241007T095142Z
BEGIN:VEVENT
DTSTART;VALUE=DATE:20241028
DTEND;VALUE=DATE:20241029
LOCATION:
SUMMARY;LANGUAGE=DE:KU1 (Nr.1)
UID:<vertraulich>
DTSTAMP:20241022T085438Z
CLASS:PUBLIC
END:VEVENT
[...]
END:VCALENDAR

Ich kann nur davon ausgehen dass Google hier ziemlich hart und global cached. Vorerst mache ich das Ticket nicht nochmal auf. Bis das Gegeneil bewiesen ist gehe ich davon aus dass alles in Ordnung ist und sich das Problem von alleine lösen wird.

ptitmouton commented 3 weeks ago

Das Ganze bestätigt sich indem man die URL künstlich ändert. Wenn man denselben Kalender zB folgendermaßen abonniert: https://ehrenberg-gymnasium.de/data/calendar/<vertraulich>/ics?1=1

Lotta ignoriert den '?1=1'-Teil, aber Google denkt es ist eine neue URL und spuckt eine aktuelle, ungecachte Version aus. Google aktualisiert die Kalender-Abos sehr unregelmäßig und unvorhersehbar.

Auf unserer Seite ist das Problem gelöst.

wie0815 commented 3 weeks ago

Super!