feat: friendly relative dates ("10 minutes ago")

[tkuhn]

Summary

Dates that previously showed as raw ISO strings like 2026-04-16T08:27:12.954Z now render as friendly relative times ("10 minutes ago") in the viewer's local timezone, with the full pretty-printed date-time available on hover.

• Recent values → just now / 10 minutes ago / 3 hours ago / yesterday (via the browser-native Intl.RelativeTimeFormat).
• Older than a week → absolute date (16 Apr 2026).
• Hover tooltip → full form, e.g. Thursday, 16 April 2026 at 10:27:12 GMT+2.

Applied to two places:

• Query result tables — the raw-ISO case that prompted this.
• NanopubItem footer creation time — aligned to the same convention.

How it works

• Utils.friendlyDateHtml(iso, fallback) emits a <time class="friendly-date" datetime="…"> element. The datetime attribute is machine-readable; the element body is server-rendered text that stays visible if JS doesn't run.
• nanodash.js renderFriendlyDates() rewrites those elements client-side (so it gets the user's locale + timezone for free), running on load, on Wicket AJAX complete, and in updateElements(). It's idempotent.
• Utils.isDateTimeLiteral() gates which query cells get the treatment.

Caveats

• Query-table detection is pattern-based. Result strings are untyped, so they're matched by an ISO-8601 regex requiring a time component. Date-only values (2026-04-16) are left as-is, and a stray string matching the pattern would be treated as a date. A cleaner long-term fix is to have grlc mark temporal columns explicitly.
• Falls back gracefully: unparseable values keep their server-rendered text; no Intl.RelativeTimeFormat support → shows the absolute date.

Test plan

• Query view with a dateTime column shows relative text + tooltip
• Nanopub footer shows relative creation time, exact value on hover
• No-JS / unparseable value still shows the original date text

🤖 Generated with Claude Code