Date format regression: create-event modal shows US dates (MM/DD/YYYY) instead of DD.MM.YYYY #33

New issue

Closed

opened 2026-07-10 09:21:17 +00:00 by laoc · 2 comments

laoc commented

2026-07-10 09:21:17 +00:00

Owner

Dates across the app should use German format DD.MM.YYYY. This was already implemented, but the create-event modal currently shows 07/10/2026 (US format) for Startdatum/Enddatum — a regression.

Likely cause: native <input type="date"> fields render in the browser locale, so they need a text mask / custom formatting to force DD.MM.YYYY.

Tasks:

Fix the Startdatum/Enddatum fields in the create-event modal to display DD.MM.YYYY
Audit the rest of the app for other date fields/displays not using the German format

Screenshot attached.

Dates across the app should use German format **DD.MM.YYYY**. This was already implemented, but the create-event modal currently shows **07/10/2026** (US format) for Startdatum/Enddatum — a regression. Likely cause: native `<input type="date">` fields render in the browser locale, so they need a text mask / custom formatting to force DD.MM.YYYY. Tasks: - [ ] Fix the Startdatum/Enddatum fields in the create-event modal to display DD.MM.YYYY - [ ] Audit the rest of the app for other date fields/displays not using the German format Screenshot attached.

image_1783675030732_0.png

42 KiB

after-german-dates-create-modal.png

37 KiB

after-24h-time-inputs.png

38 KiB

laoc commented

2026-07-10 09:39:16 +00:00

Author

Owner

Audit result: the German date picker (EuropeanDateInput, introduced for the OER metadata form) was never rolled out to the other forms. Native <input type="date"> fields remained in:

CalendarEventModal.svelte (Startdatum/Enddatum — the reported case)
EventDateRangeFilter.svelte (discover → events → custom date range)
routes/create/publication/+page.svelte (publication date)

Fix in progress: swap all three to EuropeanDateInput (drop-in, binds the same ISO value) plus a guard test that fails if a native date input is ever reintroduced.

Audit result: the German date picker (`EuropeanDateInput`, introduced for the OER metadata form) was never rolled out to the other forms. Native `<input type="date">` fields remained in: - `CalendarEventModal.svelte` (Startdatum/Enddatum — the reported case) - `EventDateRangeFilter.svelte` (discover → events → custom date range) - `routes/create/publication/+page.svelte` (publication date) Fix in progress: swap all three to `EuropeanDateInput` (drop-in, binds the same ISO value) plus a guard test that fails if a native date input is ever reintroduced.

laoc referenced this issue

2026-07-10 09:53:53 +00:00

e2e: calendar-creation/calendar-editing tests broken by FAB and event-menu redesign (stale selectors) #39

laoc commented

2026-07-10 09:58:19 +00:00

Author

Owner

Verified end-to-end in the seeded e2e environment: the create-event modal now shows DD.MM.YYYY in Start/End Date (screenshot attached to the issue), typed German dates parse back to the ISO value the event stores, and the discover date-range filter e2e suite passes with the new inputs. A guard test (no-native-date-inputs.test.js) now fails CI if a native <input type="date"> is ever reintroduced.

Verified end-to-end in the seeded e2e environment: the create-event modal now shows DD.MM.YYYY in Start/End Date (screenshot attached to the issue), typed German dates parse back to the ISO value the event stores, and the discover date-range filter e2e suite passes with the new inputs. A guard test (`no-native-date-inputs.test.js`) now fails CI if a native `<input type="date">` is ever reintroduced.

laoc referenced this issue from a commit

2026-07-10 10:00:45 +00:00

fix(dates): German DD.MM.YYYY date inputs everywhere (#33)

laoc referenced this issue from a pull request that will close it,

2026-07-10 10:01:34 +00:00

fix(dates): German DD.MM.YYYY dates and 24-hour times everywhere #41

laoc referenced this issue from a commit

2026-07-10 10:19:23 +00:00

fix(dates): 24-hour HH:MM time inputs in the event modal (#33)

laoc closed this issue

2026-07-10 10:25:42 +00:00