0.4.0

Three of the release notes below this one were published on the same day, and came out in the order 0.2.0, 0.3.0, 0.2.1. That is not their order, or their file order, or any order at all.

Two things were wrong, and the second is the one that matters.

A date is a day, so three posts on 2026-08-01 were equal, and no comparison of their dates could separate them. And slice.sort_by is not stable, so equal posts did not merely come out in an arbitrary order: they came out in an order that could change when an unrelated post was added.

A date may carry a time

"date": "2026-01-30"
"date": "2026-01-30T14:30"
"date": "2026-01-30T14:30:05"

Optional, and midnight when absent, so every stamp written before this means what it meant. Written large unit first a stamp sorts chronologically as a string, which is what the sort already relied on; a bare date sorts at the start of its day because "" is less than "T".

The slug now breaks a tie between identical stamps, so the comparison is total and an unstable sort cannot reorder anything.

What else it fixed

<pubDate> said 00:00:00 for every post ever published, because the day was all the front matter could say. It now carries the real time.

A listing shows the day and puts the whole stamp in the <time datetime> attribute, which is what that attribute is for. <lastmod> in the sitemap stays a date: a W3C datetime needs a timezone once it carries a time, and ostat does not know one.

Upgrading

Nothing to do. A site whose posts are dated to the day builds identically, and gains an order only if it starts writing times.