Datetime fields: parse every stored value into one standard, element params included #158

New issue

Closed

opened 2026-10-07 01:22:37 +02:00 by dominik.polakovics · 1 comment

dominik.polakovics commented

2026-10-07 01:22:37 +02:00

Owner

This was generated by AI during triage.

Summary

Wherever the editor reads a datetime value, it should parse any spelling Hugo reads and hand the form one standard, RFC3339. Every save writes RFC3339. #151 does this for page properties; element params and sidecar defaults still require exact RFC3339. The maintainer asked for one standard everywhere (in #151's triage).

Current behavior

Front matter has one conversion. content.DateRFC3339 (internal/content/meta.go) turns every date spelling Hugo reads into RFC3339. The page tree and the module entries endpoint use it, and #151 routes the page properties read through it.
Element params are read as written. The browser takes element params from the parsed page (GET /api/page): block elements, inline elements in rich text, and item-collection rows. A datetime param is plain text there. The element form checks it against exact RFC3339 on save (isRFC3339 in web/src/components/fields.tsx), and so does the server (element.ValidateValues). A hand-written start="2026-07-10" therefore blocks the element's save until the date is entered again. This was found by reading the code; no shipped element has a datetime param.
Sidecar defaults must be exact RFC3339. A datetime param's or field's default: is checked at load (internal/element). default: 2026-07-10 is a load error ("is not a valid RFC3339 datetime"); checked in triage.
AGENTS.md documents the strict rule: a datetime's "stored value, the shortcode param, and any default: are always the plain RFC3339 string".

Desired behavior

Every read of a datetime value hands the form RFC3339, whatever spelling Hugo reads: page-type fields (#151), element params (block elements, inline elements, item rows) and sidecar defaults.
An untouched value saves cleanly, and the saved value is the same instant. Saves write RFC3339, so a value's spelling may change.
A stored value that can't be read as a time falls back as #151 settles it for page properties: the field's default, else empty. A sidecar default that can't be read stays a load error.
AGENTS.md and the README describe the one standard: write a datetime in any spelling Hugo reads, and the editor writes RFC3339.

Decisions

One standard everywhere (maintainer): the editor reads what Hugo reads and speaks RFC3339.
One conversion: content.DateRFC3339, as #151 settles it for front matter.
The wire format stays exact RFC3339. The form's check and element.ValidateValues don't change; the leniency lives in the reads.

Open questions

Where element params are converted. The browser reads them from the parsed page, not through a server read like the properties form.
- (a) The server converts datetime params in the GET /api/page payload, using the element schemas. That keeps one conversion, but the payload stops being a plain parse of the file.
- (b) The form converts in the browser: a second date parser, in TypeScript, that has to match Hugo's spellings.
- Recommended: (a), because of the one-conversion decision.
Sidecar defaults: accept any spelling and store RFC3339 at load (recommended: the same rule everywhere), or keep requiring exact RFC3339?

Key interfaces

content.DateRFC3339 (internal/content/meta.go).
The page payload (GET /api/page, internal/server) and the forms that read it: FormPane (initialFieldValues, nodeParamValue), inline elements (web/src/rte/RichTextField.tsx), item rows.
The datetime default check in internal/element (load.go); page-type fields reuse it (internal/pagetype).

Out of scope

Page properties: #151.
Keeping a value's original spelling on save, and honoring a site's timeZone for offset-less values.

Blocked by

#151 (it routes page properties through content.DateRFC3339 and documents front-matter dates in AGENTS.md; this issue extends both)

> *This was generated by AI during triage.* ## Summary Wherever the editor reads a `datetime` value, it should parse any spelling Hugo reads and hand the form one standard, RFC3339. Every save writes RFC3339. #151 does this for page properties; element params and sidecar defaults still require exact RFC3339. The maintainer asked for one standard everywhere (in #151's triage). ## Current behavior - **Front matter has one conversion.** `content.DateRFC3339` (`internal/content/meta.go`) turns every date spelling Hugo reads into RFC3339. The page tree and the module entries endpoint use it, and #151 routes the page properties read through it. - **Element params are read as written.** The browser takes element params from the parsed page (`GET /api/page`): block elements, inline elements in rich text, and item-collection rows. A `datetime` param is plain text there. The element form checks it against exact RFC3339 on save (`isRFC3339` in `web/src/components/fields.tsx`), and so does the server (`element.ValidateValues`). A hand-written `start="2026-07-10"` therefore blocks the element's save until the date is entered again. This was found by reading the code; no shipped element has a `datetime` param. - **Sidecar defaults must be exact RFC3339.** A `datetime` param's or field's `default:` is checked at load (`internal/element`). `default: 2026-07-10` is a load error ("is not a valid RFC3339 datetime"); checked in triage. - **AGENTS.md documents the strict rule:** a `datetime`'s "stored value, the shortcode param, and any `default:` are always the plain RFC3339 string". ## Desired behavior - Every read of a `datetime` value hands the form RFC3339, whatever spelling Hugo reads: page-type fields (#151), element params (block elements, inline elements, item rows) and sidecar defaults. - An untouched value saves cleanly, and the saved value is the same instant. Saves write RFC3339, so a value's spelling may change. - A stored value that can't be read as a time falls back as #151 settles it for page properties: the field's default, else empty. A sidecar default that can't be read stays a load error. - AGENTS.md and the README describe the one standard: write a datetime in any spelling Hugo reads, and the editor writes RFC3339. ## Decisions - **One standard everywhere** (maintainer): the editor reads what Hugo reads and speaks RFC3339. - **One conversion:** `content.DateRFC3339`, as #151 settles it for front matter. - **The wire format stays exact RFC3339.** The form's check and `element.ValidateValues` don't change; the leniency lives in the reads. ## Open questions - **Where element params are converted.** The browser reads them from the parsed page, not through a server read like the properties form. - (a) The server converts `datetime` params in the `GET /api/page` payload, using the element schemas. That keeps one conversion, but the payload stops being a plain parse of the file. - (b) The form converts in the browser: a second date parser, in TypeScript, that has to match Hugo's spellings. - Recommended: (a), because of the one-conversion decision. - **Sidecar defaults:** accept any spelling and store RFC3339 at load (recommended: the same rule everywhere), or keep requiring exact RFC3339? ## Key interfaces - `content.DateRFC3339` (`internal/content/meta.go`). - The page payload (`GET /api/page`, `internal/server`) and the forms that read it: `FormPane` (`initialFieldValues`, `nodeParamValue`), inline elements (`web/src/rte/RichTextField.tsx`), item rows. - The `datetime` default check in `internal/element` (`load.go`); page-type fields reuse it (`internal/pagetype`). ## Out of scope - Page properties: #151. - Keeping a value's original spelling on save, and honoring a site's `timeZone` for offset-less values. ## Blocked by - #151 (it routes page properties through `content.DateRFC3339` and documents front-matter dates in AGENTS.md; this issue extends both)

dominik.polakovics added the

needs-triage

enhancement

labels

2026-10-07 01:22:37 +02:00

dominik.polakovics referenced this issue

2026-10-07 01:23:24 +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-07 01:23:45 +02:00

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

dominik.polakovics referenced this issue

2026-10-07 15:21:37 +02:00

Field types defined once in Go: one definition reads, checks and writes every value #163

dominik.polakovics referenced this issue

2026-10-07 15:21:42 +02:00

Editor forms described by the server, with field checks on focus lost #164

dominik.polakovics commented

2026-10-07 15:22:00 +02:00

Author

Owner

This was generated by AI during triage.

Closing as superseded. In triage the maintainer chose to define each field type once instead of fixing datetime reads place by place:

#163 defines every field type once in Go: how it reads any spelling Hugo reads, how it is checked, and how it is written. Sidecar default: values in any spelling are part of it.
#164 has the server describe every editor form and read element params on the server. That fixes this issue's element half: a hand-written date in a block element, an item row or an inline element no longer blocks its save.

The date spellings reproduced here are acceptance criteria in both issues.

> *This was generated by AI during triage.* Closing as superseded. In triage the maintainer chose to define each field type once instead of fixing datetime reads place by place: - #163 defines every field type once in Go: how it reads any spelling Hugo reads, how it is checked, and how it is written. Sidecar `default:` values in any spelling are part of it. - #164 has the server describe every editor form and read element params on the server. That fixes this issue's element half: a hand-written date in a block element, an item row or an inline element no longer blocks its save. The date spellings reproduced here are acceptance criteria in both issues.

dominik.polakovics

2026-10-07 15:22:00 +02:00