Fix date format example in reading settings

[giffeler]

What does this PR do?

Fixes the Reading settings date format example in the admin UI so it is rendered from the configured date format string instead of always showing the hard-coded January 23, 2026 example.

For example, yyyy-MM-dd now previews as 2026-01-23.

Closes #

Type of change

• Bug fix
• Feature (requires maintainer-approved Discussion)
• Refactor (no behavior change)
• Translation
• Documentation
• Performance improvement
• Tests
• Chore (dependencies, CI, tooling)

Checklist

• I have read CONTRIBUTING.md
• pnpm typecheck passes
• pnpm lint passes
• pnpm test passes (or targeted tests for my change)
• pnpm format has been run
• I have added/updated tests for my changes (if applicable)
• User-visible strings in the admin UI are wrapped for translation (if applicable). Do not include messages.po changes except in translation PRs — a workflow extracts catalogs on merge to main.
• I have added a changeset (if this PR changes a published package)
• New features link to an approved Discussion: https://github.com/emdash-cms/emdash/discussions/...

AI-generated code disclosure

• This PR includes AI-generated code — model/tool: GPT-5 Codex

Screenshots / test output

Validated with:

pnpm --filter @emdash-cms/admin typecheck
pnpm --filter @emdash-cms/admin exec vitest run tests/date-format-example.test.ts
pnpm changeset status --since=origin/main
pnpm exec prettier --check packages/admin/src/components/settings/GeneralSettings.tsx packages/admin/src/lib/date-format-example.ts packages/admin/tests/date-format-example.test.ts .changeset/fix-admin-date-format-example.md

I did not run the full repository lint or full test suite; this PR is scoped to the admin date format preview helper and its targeted test.

[changeset-bot]

🦋 Changeset detected

Latest commit: 880e564

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 16 packages

Name	Type
@emdash-cms/admin	Patch
emdash	Patch
@emdash-cms/cloudflare	Patch
@emdash-cms/sandbox-workerd	Patch
@emdash-cms/fixture-perf-site	Patch
@emdash-cms/perf-demo-site	Patch
@emdash-cms/cache-demo-site	Patch
@emdash-cms/do-demo-site	Patch
@emdash-cms/do-solo-demo-site	Patch
@emdash-cms/auth	Patch
@emdash-cms/blocks	Patch
@emdash-cms/gutenberg-to-portable-text	Patch
@emdash-cms/x402	Patch
create-emdash	Patch
@emdash-cms/auth-atproto	Patch
@emdash-cms/plugin-embeds	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[giffeler]

I have read the CLA Document and I hereby sign the CLA

[giffeler]

recheck

[emdashbot]

Approach

This is a small, well-scoped bug fix and the approach is sound. The Reading settings "Date Format" example was hard-coded to January 23, 2026 regardless of the configured format string — genuinely misleading, since e.g. yyyy-MM-dd previewed as January 23, 2026. Rendering a preview from a token-string format (MMMM d, yyyy, yyyy-MM-dd) requires a token-based formatter, which native Intl/toLocaleDateString can't do — the rest of the admin uses Intl for display dates, but those take an options object, not token strings. So introducing a token formatter here is justified, and date-fns is the standard, tree-shakeable choice whose Unicode-token dialect matches the setting's documented "date format token string" contract (and the backend default "MMMM d, yyyy"). As a nice side effect, the PR also wraps the previously untranslated description in t, fixing a Lingui leak that existed on main.

One thing for the maintainer to consciously accept: this is the first date library in the repo and a new runtime dependency on a published package (@emdash-cms/admin), adding supply-chain surface in a repo that is deliberately strict about deps (minimumReleaseAge, strictDepBuilds, blockExoticSubdeps). I judge it warranted here, but it's the one taste call worth a deliberate nod rather than a silent merge.

What I checked

• Helper logic (date-format-example.ts): format is wrapped in try/catch → null on bad input; the reference date new Date(2026, 0, 23, 12) is well-chosen (day=23 disambiguates MM/dd vs dd/MM; noon local can't roll the date across a TZ boundary, so date-only previews are TZ-stable). The internal dateFormat || DEFAULT_DATE_FORMAT is redundant given the caller already guards, but it's harmless defensiveness.
• Component (GeneralSettings.tsx): value={dateFormat} is behaviorally identical to the old formData.dateFormat || "MMMM d, yyyy" (default shown but not persisted into state — same as before, not a regression). The description now has a valid/invalid branch, both correctly wrapped with t and using interpolation (not concatenation), so word order is translator-safe. ICU-injection from user-typed format strings isn't a concern — interpolated values are runtime args, not part of the message pattern.
• i18n / RTL: no new untranslated strings; no messages.po included (correct — the workflow extracts on merge). The → arrow is pre-existing and now translatable, so translators can adapt it for RTL; not a regression.
• Consistency: DEFAULT_DATE_FORMAT = "MMMM d, yyyy" matches the backend default asserted in packages/core/tests/unit/settings/settings.test.ts. No other call sites referenced the old hard-coded example.
• Changeset: present, @emdash-cms/admin: patch, appropriate for a pre-1.0 bug fix. date-fns is correctly in dependencies (it's bundled into the shipped dist).
• Tests: a reproducing test exists covering the default, an ISO variant, and the null path.

I could not run the test/build myself (date-fns isn't installed in the sandbox and I review statically), so the build/typecheck/test-pass claims are taken on the author's report. My static reading of date-fns format — it throws on unknown letter sequences (e.g. the n in "nope") — is consistent with the "yyyy-MM-dd nope" → null assertion, so the test is not obviously false-confidence.

Conclusion

Clean, correct, well-tested fix that also tightens i18n. Mergeable as-is; the only actionable note is a minor test-placement convention nit.

[emdashbot]

[suggestion] Pure src/lib/* helper tests live in tests/lib/ (e.g. datetime-local.test.ts, url.test.ts, utils.test.ts, markdown.test.ts — 14 files mirroring src/lib/). This test for src/lib/date-format-example.ts is placed at the top level of tests/ instead, where the only other top-level tests (router.test.tsx, editor-focus.test.tsx, byline-form-customfields.test.tsx) cover cross-cutting features rather than a single src/lib module. Move it to tests/lib/date-format-example.test.ts to match the mirror-source convention; the import would then become from "../../src/lib/date-format-example". (It still matches the tests/**/*.test.{ts,tsx} glob either way, so this is placement only — no runtime impact.)