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.