🌍 Neue Kalenderfunktion: Lokale Zeit anzeigen

sam · 4. Juni 2025 um 23:03

Können wir die führende Null weglassen

Das ist meiner Meinung nach eine große Verbesserung.

nathank · 6. Juni 2025 um 02:04

Ah, das habe ich übersehen, dass du von wiederkehrenden Ereignissen gesprochen hast, Entschuldigung!

yuriy · 23. Juni 2025 um 09:46

Ich habe eine Weile an dieser Aufgabe gearbeitet, seit letzter Woche. Ich sehe, dass sie in drei Abschnitte und eine Frage gegliedert werden kann:

Vermeiden Sie Duplikate und Unklarheiten bei von -\u003e bis-Bereichen:
- aktuelles Jahr, keine Zeiten (00:00):
  - gleicher Wochen-/Monatsbereich: Mo, 6. Okt → Fr, 10. Okt || Mo, 6. Okt → Mo, 20. Okt
  - Bereich über verschiedene Monate: Mo, 6. Okt → Do, 6. Nov
- aktuelles Jahr, mit Zeiten:
  - Bereich am selben Tag: Mo, 6. Okt 12:00 → 1:00 Uhr
- verschiedene Jahre, keine Zeiten: Mo, 6. Okt → Di, 6. Jan 2026
Lokale Zeit basierend auf aktiviertem Kontrollkästchen anzeigen (im OP)
Ich habe einige Inkonsistenzen festgestellt, wenn wir Daten innerhalb des Bereichs zwei Tage vor und einen Tag nach heute anzeigen:
- mit Zeit: Gestern/Heute/Morgen 20:00 Uhr
- ohne Zeit: Montag...Sonntag
Manchmal wird die Zeitzone am Ende des Datums und der Uhrzeit angezeigt: Heute 14:00 → 16:00 Uhr (UTC). Frage: In welchen Fällen möchten wir die Zeitzone in Klammern anzeigen?

yuriy · 23. Juni 2025 um 13:46

Ich habe zwei zusammenhängende PRs:

github.com/discourse/discourse-calendar

UX: smart format dates

main ← better-format-dates

opened 10:37AM - 13 Jun 25 UTC

jjaffeux

+270 -9

This PR overhauls the way event dates are rendered by applying context-aware for…matting rules: * Single-day events only show times when appropriate, hiding “12:00 AM” for events without `endDate`. * Multi-day ranges omit redundant parts (e.g. for the current year) and include weekday/month/day when needed. ### Tests added * Weekday-only ranges (e.g. “Friday → Monday”) * Same-week and same-month spans (omitting year) * Cross-month and cross-year spans (including year where needed) * `Today/Yesterday/Tomorrow` labels with time ranges * Same-day events showing only time ### Impact * Improves readability of event dates across the app * Reduces visual noise by hiding redundant date/time fragments * Ensures consistency with user expectations around relative dates ### Things to clarify * Relative labels (`Yesterday, Today, Tomorrow`) replace literal dates for nearby days. * Timezones are only shown when `showLocalTime` is toggled. ### Discussion https://meta.discourse.org/t/new-calendar-feature-show-local-time/368608/

@nat, ich beziehe dich mit ein, da du vor Jahren an diesem Feature gearbeitet hast:

github.com/discourse/discourse

FEATURE: Omit showing day when 'to' day is same as 'from' day

main ← date-today

opened 10:08AM - 06 Oct 22 UTC

nattsw

+61 -7

Essentially, introducing this change. Saturday at 2:50 PM -> Saturday at 4:38… PM becomes Saturday at 2:50 PM -> 4:38 PM (Singapore) Also, the displayed dates are shortened when the standalone date is within two days. So despite the 'from' and 'to' date being the same day, it may show 'Saturday' for 'from', and the specific date for the 'to'. This corrects the behaviour. So if the current date and time is Thursday 5PM, the 'from' date below is within 2 days, but the 'to' date is not. Saturday at 2:50 PM -> 8 October 2022 at 9:38 PM becomes Saturday at 2:50 PM -> 9:38 PM

In welchen Fällen sollten wir einen Zeitzonennamen in Klammern nach dem von/bis-Datum/Uhrzeit anzeigen?
Was sind die Erwartungen für die Anzeige: Wochentagsname Montag...Sonntag oder Gestern/Heute/Morgen?

Ich würde mich für Folgendes entscheiden:
- Gestern/Heute/Morgen: für -1 Tag<-Heute->+1 Tag
- Montag...Sonntag: innerhalb der aktuellen Woche oder -3 Tage<-Heute->+3 Tage
Das Vorhandensein der Uhrzeit sollte kein entscheidender Faktor dafür sein, welche der beiden obigen Optionen angezeigt wird, wie es jetzt der Fall ist:
- keine Uhrzeit: Montag...Sonntag
- mit Uhrzeit: Gestern/Heute/Morgen

yuriy · 23. Juni 2025 um 13:51

Wir sind bereit, den ersten PR zusammenzuführen. Es ist nicht ideal, da die Behebung von Randfällen, die in meinem vorherigen Beitrag aufgeführt sind, folgen könnte.

github.com/discourse/discourse-calendar

UX: smart format dates

main ← better-format-dates

opened 10:37AM - 13 Jun 25 UTC

jjaffeux

+270 -9

This PR overhauls the way event dates are rendered by applying context-aware for…matting rules: * Single-day events only show times when appropriate, hiding “12:00 AM” for events without `endDate`. * Multi-day ranges omit redundant parts (e.g. for the current year) and include weekday/month/day when needed. ### Tests added * Weekday-only ranges (e.g. “Friday → Monday”) * Same-week and same-month spans (omitting year) * Cross-month and cross-year spans (including year where needed) * `Today/Yesterday/Tomorrow` labels with time ranges * Same-day events showing only time ### Impact * Improves readability of event dates across the app * Reduces visual noise by hiding redundant date/time fragments * Ensures consistency with user expectations around relative dates ### Things to clarify * Relative labels (`Yesterday, Today, Tomorrow`) replace literal dates for nearby days. * Timezones are only shown when `showLocalTime` is toggled. ### Discussion https://meta.discourse.org/t/new-calendar-feature-show-local-time/368608/

Thema		Antworten	Aufrufe
Show timezone/locale on event dates/times, and show admins how it is determined Feature calendar-and-event	0	208	15. Februar 2024
Events Plugin :calendar: Plugin	866	88618	12. September 2025
Date line should be human-readable in mails Feature email , calendar-and-event , completed	21	553	29. Mai 2025
Discourse Calendar (and Event) Plugin official , calendar-and-event , included-in-core	101	54335	12. November 2025
Discourse local dates need better presentation in emails UX	12	2232	19. November 2019

🌍 Neue Kalenderfunktion: Lokale Zeit anzeigen

Verwandte Themen