From 5d3dbebd77fc0b1465f4b33d929fdc1a48d0a06f Mon Sep 17 00:00:00 2001 From: Bernard Siebens Date: Sun, 16 Aug 2026 09:54:48 +0200 Subject: [PATCH] Fix Safari rejecting the news publish-date field with no step attribute defaults to whole-minute granularity, but the value was rendered via the "c" filter (full ISO, always includes seconds) -- NewsPublishForm's initial=timezone.now made every render carry live, non-zero seconds, which violates that implicit step. Chrome tolerates the mismatch; Safari enforces it and silently refuses to accept the field, with no server-side validation error to explain why. Format datetime-local values at minute precision instead. Fixes every field using this widget (event start/end/gathering/deadline, series dtstart/until), not just the one this was noticed on. Co-Authored-By: Claude Sonnet 5 --- controlpanel/templates/templatetags/field.html | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/controlpanel/templates/templatetags/field.html b/controlpanel/templates/templatetags/field.html index 24679be..5c1494b 100644 --- a/controlpanel/templates/templatetags/field.html +++ b/controlpanel/templates/templatetags/field.html @@ -18,11 +18,20 @@
{% if field_type == "input" %} + {% comment %} + datetime -> minute precision (Y-m-d\TH:i), not "c": a + with no `step` attribute defaults to whole-minute granularity, and a + pre-filled value carrying seconds (e.g. NewsPublishForm's `initial=timezone.now`, + live to the second) violates that step. Chrome quietly tolerates the + mismatch; Safari enforces it and refuses to submit the field at all, + with no server-side validation error to explain why -- the fix has to be + not sending a value more precise than the field claims to accept. + {% endcomment %}