Skip to content

intent: duplicable defaults take now on a timestamp field (#7396) - #7423

Merged
delchev merged 1 commit into
masterfrom
issue-7396-duplicable-now-timestamp
Sep 17, 2026
Merged

delchev merged 1 commit into
masterfrom
issue-7396-duplicable-now-timestamp

Conversation

@delchev

@delchev delchev commented Sep 17, 2026

Copy link
Copy Markdown
Contributor

IntentParser.validateDuplicableDefault accepted now on a date / month / week
field and refused everything else, so

duplicable:
  defaults: { recordedAt: now }   # recordedAt is `type: timestamp`

failed validation with "that property is not a date" - although a timestamp
property holds exactly the kind of value now means. date and timestamp
differ only in precision, and the copy of a document is made now in both cases,
so the refusal ruled out the one value an author would write there and left a
calculatedActionOnCreate class, or a clone carrying the source's timestamp, as
the only ways to say it.

The sibling of #7392 on the duplicable path, and one rendering step further than
it, because this half renders in JavaScript rather than Java:

  • validateDuplicableDefault reads the accepted types from a named set, so a
    temporal type added later is one line and not another equals chain;
  • EdmIntentGenerator.duplicateDefaults emits the AUTHORED shape instead of
    collapsing everything that is not month/week to date;
  • todayAs in document-page.js.template renders a timestamp as the ISO
    instant - the same conversion the form's own toPayload() already does for a
    datetime input, since a java.time.Instant property does not bind the local
    calendar shapes the other kinds send. The calendar shapes stay built from the
    LOCAL fields: east of Greenwich toISOString() dates an evening copy
    yesterday, which is why the timestamp shape is the deliberate exception and
    not a relaxation of that rule.

A model that declares no timestamp default generates byte-identically.

Verified: DuplicableIntentTest accepts now on a timestamp field and still
refuses it on a string and on a to-one relation (whose default assigns a raw
foreign key), 20 tests green; EdmIntentGeneratorTest asserts the emitted
shape: timestamp next to the unchanged date / month / literal entries; the
engine-intent unit suite is green (1327 tests); IntentEmissionCoverageIT now
carries a timestamp field on Reorder with a now default and asserts both
the generated todayAs('timestamp') assignment and the helper's instant branch
in the published document page - green, and the module it publishes compiles.
Not run: the full IT suite, and no browser pass on a real Duplicate click.

Fixes #7396

🤖 Generated with Claude Code

`IntentParser.validateDuplicableDefault` accepted `now` on a date / month / week
field and refused everything else, so

    duplicable:
      defaults: { recordedAt: now }   # recordedAt is `type: timestamp`

failed validation with "that property is not a date" - although a timestamp
property holds exactly the kind of value `now` means. `date` and `timestamp`
differ only in precision, and the copy of a document is made now in both cases,
so the refusal ruled out the one value an author would write there and left a
`calculatedActionOnCreate` class, or a clone carrying the source's timestamp, as
the only ways to say it.

The sibling of #7392 on the duplicable path, and one rendering step further than
it, because this half renders in JavaScript rather than Java:

- `validateDuplicableDefault` reads the accepted types from a named set, so a
  temporal type added later is one line and not another `equals` chain;
- `EdmIntentGenerator.duplicateDefaults` emits the AUTHORED shape instead of
  collapsing everything that is not month/week to `date`;
- `todayAs` in `document-page.js.template` renders a `timestamp` as the ISO
  instant - the same conversion the form's own `toPayload()` already does for a
  datetime input, since a `java.time.Instant` property does not bind the local
  calendar shapes the other kinds send. The calendar shapes stay built from the
  LOCAL fields: east of Greenwich `toISOString()` dates an evening copy
  yesterday, which is why the timestamp shape is the deliberate exception and
  not a relaxation of that rule.

A model that declares no timestamp default generates byte-identically.

Verified: `DuplicableIntentTest` accepts `now` on a timestamp field and still
refuses it on a string and on a to-one relation (whose default assigns a raw
foreign key), 20 tests green; `EdmIntentGeneratorTest` asserts the emitted
`shape: timestamp` next to the unchanged date / month / literal entries; the
engine-intent unit suite is green (1327 tests); `IntentEmissionCoverageIT` now
carries a `timestamp` field on `Reorder` with a `now` default and asserts both
the generated `todayAs('timestamp')` assignment and the helper's instant branch
in the published document page - green, and the module it publishes compiles.
Not run: the full IT suite, and no browser pass on a real Duplicate click.

Fixes #7396

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@delchev
delchev merged commit 359391f into master Sep 17, 2026
10 checks passed
@delchev
delchev deleted the issue-7396-duplicable-now-timestamp branch September 17, 2026 12:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

intent: duplicable: defaults { <timestampField>: now } is refused at parse - the one value an author would write there

1 participant