Page Settings: datetime field from disk fails validation until re-entered #133

New issue

Open

opened 2026-07-19 19:22:58 +02:00 by dominik.polakovics · 0 comments

dominik.polakovics commented

2026-07-19 19:22:58 +02:00

Owner

Found while verifying #130 with a real browser against harness serve (not caused by #130 — the datetime field predates it).

Repro:

Hand-write a news item with date = 2026-07-10T09:00:00Z in front matter (TOML, as the scaffold writes it).
harness serve, open the item's Page Settings in the editor.
The Publish date input displays the value fine (07/10/2026, 11:00:00 AM in a UTC+2 browser).
Click Save without touching the date → red "Must be a valid date and time" under the untouched field; the save is blocked.
Re-fill the input with the same instant (e.g. 2026-07-10T11:00) → save succeeds and writes date = "2026-07-10T11:00:00+02:00".

So a page whose date came from disk (hand-authored, or authored in another timezone?) cannot be saved from Page Settings until the author re-enters the date. Suspect the round-trip into the datetime-local input (seconds component and/or timezone conversion) produces a value the client-side datetime validation rejects.

Observed on branch afk/130 (engine state = main + #128/#129).

Found while verifying #130 with a real browser against `harness serve` (not caused by #130 — the datetime field predates it). **Repro:** 1. Hand-write a news item with `date = 2026-07-10T09:00:00Z` in front matter (TOML, as the scaffold writes it). 2. `harness serve`, open the item's Page Settings in the editor. 3. The Publish date input displays the value fine (`07/10/2026, 11:00:00 AM` in a UTC+2 browser). 4. Click Save without touching the date → red "Must be a valid date and time" under the untouched field; the save is blocked. 5. Re-fill the input with the same instant (e.g. `2026-07-10T11:00`) → save succeeds and writes `date = "2026-07-10T11:00:00+02:00"`. So a page whose date came from disk (hand-authored, or authored in another timezone?) cannot be saved from Page Settings until the author re-enters the date. Suspect the round-trip into the `datetime-local` input (seconds component and/or timezone conversion) produces a value the client-side datetime validation rejects. Observed on branch afk/130 (engine state = main + #128/#129).

dominik.polakovics added the

needs-triage

label

2026-07-19 19:22:58 +02:00

dominik.polakovics referenced this issue

2026-07-19 19:23:43 +02:00

feat(news): categories field on news items + category filter on news-list #134