Clock: optional tz.library support for a DST-aware UTC-offset guess

[sidick]

docs/CLOCK.md seeds the amber UTC-offset guess from locale.library's loc_GMTOffset, and its documented weaknesses are exactly the ones a real timezone database fixes: no DST awareness, and a fixed offset that goes stale twice a year.

The IANA tz database has a maintained classic-Amiga port — "Timezone Database & Library" (Aminet util/time/tz.lha v7.18 / tz8.lha v8.20, dev package tzdev.lha) — providing tz.library with full tzdata, i.e. DST-correct local→UTC conversion. Precedent in our exact niche: AmiAuthenticator (Aminet util/wb/AmiAuthenticator) already offers it as one of its three time sources.

Proposal:

• At clock init, runtime-detect tz.library. When present and configured, derive the local→UTC offset from it instead of loc_GMTOffset.
• Still amber, not green — tzdata fixes the offset, but the underlying RTC can still be wrong. SNTP remains the only path to CLOCK_SYNCED, and the manual nudge still applies on top.
• Fallback chain becomes: SNTP → tz.library → loc_GMTOffset → manual nudge.
• Never required — the zero-mandatory-deps rule applies. Same optional runtime-dispatched provider pattern as AmiSSL (Optional AmiSSL-backed crypto provider (CRYPTO=BUILTIN|AMISSL|AUTO) #85).
• Mind the sign conventions: CLOCK.md already flags the loc_GMTOffset minutes-west footgun; verify tz.library's convention independently rather than assuming it matches.

Wiki: the clock/time-sources page gets the new source and priority order when this lands.

[sidick]

Addendum: the API is solid, but the bundled tzdata is stale (2020a)

Downloaded and inspected the actual packages (tz.lha v7.18, tz8.lha
v8.20, tzdev.lha) rather than going on the readme summary alone. The API
itself is more than sufficient — full POSIX time.h (tzset/mktime/
localtime/gmtime/...) plus Amiga-native bridging (Amiga2Unix/
Unix2Amiga, Tm2DateStamp/DateStamp2Tm), all DST-aware via real IANA
tzdata under the hood.

Integration point confirmed via the library's own regression test:
GetLocalTimezone(GetTime(), &tz) → tz.tz_minuteswest uses the same
sign convention as loc_GMTOffset (minutes west), so it's a close
drop-in for the existing cli_utc_offset() code — just DST-correct
per-instant instead of a fixed value. Watch out for GmtOffset() (a
different function in the same library) — confirmed via
GmtOffset(now) == tz.tz_minuteswest * -60 in the library's own test suite
that it uses the opposite convention (seconds east). Graceful
degradation is built in: SetTimezone() documents falling back to UTC
(offset 0) if TZ isn't set and ENV:Localtime isn't valid, rather than
erroring.

But: both the library (last release 8.20, June 2020, "synced code to
tz release 2020a") and its separate tzdata package (uploaded May 2020,
IANA 2020a, released 2020-04-23) haven't been updated since. No newer
fork or maintained alternative found. Current upstream IANA tzdata is at
2026a (April 2026) — six years and dozens of releases of accumulated
political/DST rule changes this package won't reflect: Jordan dropping DST
(2022), Mexico eliminating most DST zones (2022), Iran dropping DST
(2022), Chile's repeated DST rule changes, Greenland's 2023 change, and
more.

The library's own TZif parser is fine (stable format, would read
freshly-compiled zone data from a current IANA release without needing a
binary update), but there's no maintained source of fresher Amiga-targeted
tzdata to point it at — anyone following the documented install gets
2020a rules.

Practical effect: still a real improvement over loc_GMTOffset for
the common case (most zones' rules predate 2020 and haven't changed), but
for the specific zones that have changed since, tz.library would report
a wrong offset with more apparent authority ("DST-aware, from real
tzdata") than the honestly-static loc_GMTOffset fallback — arguably a
worse failure mode than what exists today, since it looks more
trustworthy than it actually is for those cases.

Revised recommendation: still worth the (small) integration effort
when picked up, but:

• Stay amber, as already specified — this doesn't change that call.
• The docs/CLOCK.md writeup and any user-facing wiki page should
  explicitly note the bundled tzdata is a 2020 snapshot, not
  unqualified "DST-correct," so nobody overstates the guarantee.
• Worth rechecking Aminet for a fresher release before implementing, in
  case this changes between now and whenever this gets picked up.

[sidick]

Decision: not pursuing this, staying on locale.library alone

Leaning away from implementing tz.library support. The loc_GMTOffset
fallback is wrong in a consistent, predictable way (static, no DST) —
that's a known, boundable failure mode a user can reason about. Stale
tz.library data (frozen at 2020a, per the addendum above) would be right
for most zones/dates but silently, unpredictably wrong for the specific
zones whose DST rules changed since 2020 — a worse property for something
that's supposed to be a trustworthy amber signal, since it looks more
authoritative than it is.

Leaving this open rather than closing outright — the calculus changes if
a fresher, maintained Amiga tzdata source ever turns up, so keeping the
research here for whoever revisits it.