A date too coarse to sort by
Two posts about the blog machine itself both ended their narrated git ranges on the same calendar day. The frontmatter date field had no way to say which came first.
This blog’s own post date had always come from the last commit in whatever git range a post narrates, but only the calendar day, YYYY-MM-DD, discarding the actual time. That was fine until two posts landed on the same day: one narrating the blog machine’s first drafts, the other narrating fixes to the interface layer, both ending their ranges on 2026-07-14, hours apart in real git history but indistinguishable once truncated to a bare date. Whatever order they happened to render in stopped reflecting the order the commits actually happened in.
The fix keeps the whole timestamp instead of throwing away the hours: frontmatter now stores the complete ISO 8601 value, offset included, straight from git’s own authored-timestamp format, for every post drafted from here on. The page still shows only the date to a reader, since nobody needs the minute a post’s underlying commit landed, but the site sorts on the full stored value, so two posts sharing a calendar day keep the order their git history actually put them in rather than whatever the frontmatter’s precision happened to allow.