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

New issue

Closed

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

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

dominik.polakovics referenced this issue

2026-10-06 00:09:19 +02:00

Fix datetime round-trip in page properties (#133), shared news cards, shown fields per page type #151

dominik.polakovics referenced this issue

2026-10-06 00:25:34 +02:00

Editor modules declared in YAML by feature bundles; News module replaces the List module #153

dominik.polakovics commented

2026-10-07 01:23:45 +02:00

Author

Owner

This was generated by AI during triage.

Closing as a duplicate of #151, which now carries the fix as a full brief.

Triage reproduced this on main. The cause is on the server, not in the datetime-local round trip this report suspected. The settings read stringifies front-matter values with cast.ToStringE, so a native TOML datetime (date = 2026-07-10T09:00:00Z) reaches the form as Go's 2026-07-10 09:00:00 +0000 UTC, which isn't RFC3339. The browser's check rejects it, and so would the server's.

It is wider than TOML datetimes with an offset. Local TOML datetimes, date-only values (TOML, YAML, JSON) and YAML's 2026-07-10 09:00:00 are blocked the same way. #151 routes the settings read through content.DateRFC3339, the conversion the page tree and the module entries already use, and its PR links back here. Every other datetime read (element params, sidecar defaults) is #158.

> *This was generated by AI during triage.* Closing as a duplicate of #151, which now carries the fix as a full brief. Triage reproduced this on `main`. The cause is on the server, not in the `datetime-local` round trip this report suspected. The settings read stringifies front-matter values with `cast.ToStringE`, so a native TOML datetime (`date = 2026-07-10T09:00:00Z`) reaches the form as Go's `2026-07-10 09:00:00 +0000 UTC`, which isn't RFC3339. The browser's check rejects it, and so would the server's. It is wider than TOML datetimes with an offset. Local TOML datetimes, date-only values (TOML, YAML, JSON) and YAML's `2026-07-10 09:00:00` are blocked the same way. #151 routes the settings read through `content.DateRFC3339`, the conversion the page tree and the module entries already use, and its PR links back here. Every other datetime read (element params, sidecar defaults) is #158.

dominik.polakovics

2026-10-07 01:23:45 +02:00