Publish v0.6.0

[carpentry-agent]

Last tag 0.5.3, cut 2026-08-15 (12 days ago). 4 commits on master since (2 excluding merges). No CHANGELOG in this repo, so this is a summary of the log.

What is unreleased

Both commits are correctness fixes to 64-bit arithmetic that narrowed through a 32-bit C long.

Datetime.to-unix-timestamp wrapped past 2038 (#27, a511342). It multiplied the day count by DAY in 32-bit Int, so 2100-01-01 came out as -192522496 and 2262-04-11 as 633351808. from-unix-timestamp divided the same way, so a wrapped value decoded to a wrong date instead of being rejected. to-unix-timestamp now returns Long and from-unix-timestamp takes one; the widening happens at the multiplication, and DAY/HOUR/MINUTE/SECOND stay Int since only the day count can overflow.

Datetime.now's nanoseconds field was a function of the truncated low 32 bits (#26, 69c7290). Uint64.to-long is return (long)x;, and C long is 32 bits on every ILP32 target — 32-bit Linux, armhf, and Windows x64 — so the modulo ran on the sign-extended low word. It wrapped discontinuously about every 4.29 s of wall clock and could return a negative nanoseconds field outright. Every runner in this org's CI is 64-bit, which is why it survived. The reduction now stays in Uint64 and lives in a new Datetime.subsecond-nanos.

Plus their tests (+132 lines in test/time.carp) and regenerated docs/Datetime.html.

Version

Minor → 0.6.0. Two public functions changed signature (to-unix-timestamp Int → Long, from-unix-timestamp Int → Long) and one is new (subsecond-nanos). Nothing was removed. 0.5.4 would understate it — a caller passing an Int literal stops compiling.

Notes for the bump

• Both in-org consumers pin 0.5.3, so nothing breaks on the tag itself. http/http.carp:3 pins time@0.5.3 and calls (Datetime.from-unix-timestamp 0) at http.carp:176, which needs 0l when that pin moves. llm reaches time transitively through http-client@0.5.4 and calls to-unix-timestamp at llm.carp:264-265. Both are separate follow-ups, not part of this tag.
• This release is a prerequisite for retiring a workaround. Retry rate limits and server errors with exponential backoff llm#19 carries a local overflow guard for Retry-After HTTP-dates precisely because to-unix-timestamp wraps at the pinned version, and you noted on that PR that the guard's mechanism "rests on C signed-int overflow in time's to-unix-timestamp, which is UB, so clang at -O2 isn't obliged to preserve even the tested year-2100 wrap-negative path". The guard can only be replaced by real arithmetic once time ships this and http/http-client/llm pick it up.

---

Opened by the carpentry-org heartbeat agent (Claude). Veit has not reviewed this yet.

[carpentry-agent]

Correction to my own second bullet, which went stale about twenty minutes after I wrote it.

I said this release was "a prerequisite for retiring a workaround" in carpentry-org/llm#19. It is not, any more. 0ff0882 on that branch makes the guard value-based: seconds-until no longer calls Datetime.to-unix-timestamp at all, working from the UTC ordinal difference and the two times-of-day instead, with a day-difference bound of 24854 that keeps every reachable value inside Int. So nothing there rests on the overflow any more, and llm is not waiting on this tag.

That also corrects the reachability claim: llm has no time pin of its own. The chain is llm → http-client@0.5.4 → http@0.4.2 → time@0.5.3, so picking this release up over there needs an http release and then an http-client release first — it was never one bump.

The rest of the issue stands. Both fixes are still real, both consumers still pin 0.5.3, and http.carp:176 still needs 0l whenever that pin moves.