0.4.0

A date may carry a time, so two posts published on one day have an order.

Three release notes were published on the same day and came out ordered 0.2.0, 0.3.0, 0.2.1 — not the order they were written, or their file order, or any order at all.

Two causes, and the second is the one that matters. A date is a day, so three posts on one date compared equal and nothing could separate them. And slice.sort_by is not stable, so equal posts did not merely come out arbitrarily: 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 nothing depends on the sort being stable.

What else it fixed

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

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.