Update timezone client to RFC 7808 (path-based) + working default server

[karora]

aCal's timezone client (service/UpdateTimezones) speaks the obsolete draft-douglass-timezone-service API (?action=list, ?action=get&tzid=…), built from R.string.bedeworkOrgTzUrl = http://www.bedework.org/.well-known/timezone (res/values/unlocalisable_strings.xml).

RFC 7808 (the published standard) is path-based: {context}/capabilities, {context}/zones, {context}/zones/{tzid}. Because aCal uses the old draft, it fails against compliant servers — so timezone data is effectively broken out of the box for anyone who hasn't hand-configured a server.

The current default (bedework) is unusable three ways: expired TLS cert, stale IANA 2020bj data, and a /.well-known/timezone that doesn't redirect to its /tzsvr service. (See comments for the full server survey.)

Tasks

• Convert UpdateTimezones to RFC 7808:
  • list → GET {context}/zones (response: {"synctoken":…,"timezones":[{tzid,last-modified,etag},…]})
  • get → GET {context}/zones/{tzid} (response: VTIMEZONE)
  • read synctoken from the list response — it currently reads dtstamp, which RFC 7808 does not return.
  • treat tzServerBaseUrl as the service context path; discover it by following the /.well-known/timezone redirect (capability check via {context}/capabilities).
  • the existing timezones[] / tzid / last-modified parsing carries over.
• Choose and verify a working public default server (move to https://). davical.mcmillan.nz/timezones is a confirmed-working RFC 7808 reference/test target with current 2026 data, but a personal server — pick a suitable public default (public DAViCal-go instance, or self-hosted).
• Consider renaming bedeworkOrgTzUrl, which will no longer be bedework.

Acceptance criteria

• UpdateTimezones fetches via RFC 7808 path endpoints and ignores the old ?action= form.
• List parsing reads synctoken; per-zone last-modified change detection still works.
• A fresh install fetches current timezones successfully with no manual configuration, against the new default.
• Verified end-to-end against davical.mcmillan.nz/timezones.

Related: #4 (per-server timezone-service discovery, built on the same RFC 7808 client).

[karora]

Research: candidate timezone sources (tested 2026-06-08)

The app's current client (UpdateTimezones) speaks the Bedework/TZDIST model: ?action=list (JSON {"timezones":[…]} + change timestamps), then ?action=get&tzid=… (VTIMEZONE). Tested candidates against that:

Candidate	Result
bedework.org (current default)	Broken.
tzinfo.org	Not TZDIST — /.well-known/timezone redirects to a marketing site; it's a REST UTC-offset API, wrong schema.
tz.calendarserver.org (Apple CalendarServer)	Dead — DNS does not resolve (calendarserver.org retired).
davical.mcmillan.nz	/.well-known/timezone routes to the CalDAV handler (Allow: OPTIONS, PROPFIND, REPORT, POST), returns 405 to GET. No TZDIST service wired at the well-known path.
tzurl.org	Live, maintained, current data (Olson 2026a), HTTPS. Serves valid VCALENDAR/VTIMEZONE at https://www.tzurl.org/zoneinfo/<TZID> (verified Pacific/Auckland). But path-based per-zone — no ?action=list API.

Conclusion

The classic TZDIST action=list servers are gone/unmaintained. tzurl.org is the only live source, but it is not a drop-in URL swap — it has no list endpoint and uses a path (/zoneinfo/<TZID>) rather than ?action=get&tzid=.

Recommended direction: adapt UpdateTimezones to fetch tzurl.org/zoneinfo/<TZID> on demand (when an event references an unknown TZID) instead of the periodic bulk action=list sync. This is lighter than the current bulk download of every zone, and removes the dependency on a list API that no public server reliably provides.

Knock-on for #4

On davical.mcmillan.nz, DAViCal does not expose a TZDIST service at /.well-known/timezone (it falls through to CalDAV). So the per-server discovery in #4 would find nothing here unless DAViCal's timezone service is enabled/served at that path — worth confirming what DAViCal actually exposes before building discovery around it.

[karora]

Correction — earlier findings used the wrong API

My first comment probed every server with the obsolete ?action=list / ?action=get draft (draft-douglass-timezone-service). That is also the API aCal's UpdateTimezones currently uses. RFC 7808 is path-based: {context}/capabilities, {context}/zones, {context}/zones/{tzid}. Re-tested with the correct endpoints:

Server	RFC 7808?	Verdict
davical.mcmillan.nz/timezones	✅ yes	Working, current (2026) data (DAViCal-go). /zones returns {"synctoken":…,"timezones":[…]}; /zones/Pacific/Auckland returns VTIMEZONE.
bedework.org/tzsvr	✅ paths exist	Unusable: expired TLS cert + stale IANA 2020bj data + /.well-known/timezone doesn't redirect to /tzsvr.
tzurl.org	❌ no	Current data but only its own /zoneinfo/{tzid} path; no /zones, no well-known.
tz.calendarserver.org	—	Dead (DNS gone).
tzinfo.org	❌ no	REST offsets / marketing site.

Real root cause

aCal speaks the obsolete draft, so it fails against modern RFC 7808 servers. This is the core bug, not merely "the default server died."

Plan (reframed)

1. Make UpdateTimezones an RFC 7808 client:
   • list: GET {context}/zones (was ?action=list)
   • get: GET {context}/zones/{tzid} (was ?action=get&tzid=)
   • read synctoken from the list response (currently reads dtstamp, which RFC 7808 does not return → breaks)
   • tzServerBaseUrl becomes the service context path; discover it by following the /.well-known/timezone redirect
   • The timezones[] / tzid / last-modified parsing carries over unchanged.
2. Pick a working public default. davical.mcmillan.nz/timezones proves the client works and is a good test target, but it's a personal server — a public default still needs choosing (a public DAViCal-go instance, or one we host). Move scheme to https://.

Note for #4

davical.mcmillan.nz/.well-known/timezone currently returns 405 (routed to CalDAV) instead of redirecting to /timezones. Per-server discovery in #4 needs that well-known redirect working server-side (or a fallback that probes a default context path).

[karora]

Client conversion done (RFC 7808 path API)

service/UpdateTimezones now uses the standard endpoints:

• list → GET {context}/zones
• get → GET {context}/zones/{tzid} (tzid path-escaped with Uri.encode(tzid, "/") — keeps /, escapes spaces, so names like New Zealand Standard Time work)
• removed the legacy ?action=list/?action=get&tzid= builder and the dead dtstamp read (RFC 7808 returns synctoken); per-zone last-modified change detection is unchanged
• tzServerBaseUrl is now the service context; redirects on /zones are followed and the context recovered by stripping the trailing /zones
• renamed default resource bedeworkOrgTzUrl → defaultTzServerBaseUrl (+ res/xml/main_preferences.xml)

Builds clean. Verified end-to-end against davical.mcmillan.nz/timezones: /zones returns synctoken + tzid/last-modified, and the space-containing zone fetches via the escaped path.

Still open: the release default

davical.mcmillan.nz/timezones lists only 4 zones. Because the sync deletes local zones not in the server's list, it would prune users to those 4 — so it is a protocol reference, not a release default. The resource is marked PLACEHOLDER in unlocalisable_strings.xml.

Needs decision: a default RFC 7808 server that serves the full IANA zone set (a complete public DAViCal-go instance, or one we host). Until then the client change is complete but should not ship with this default.

[karora]

Prune guard added

UpdateTimezones no longer deletes local zones absent from the server list unless the list looks reasonably complete (serverZoneCount >= 100 or >= local zone count). A sparse/broken server, or one reached at the wrong path, now logs a warning and leaves the local set intact instead of wiping it.

Side effect: this makes the current placeholder default (davical.mcmillan.nz, 4 zones) non-destructive for existing users — pruning is skipped — though it is still not a complete default for fresh installs. The "choose a full-IANA default" item remains open (user opted to leave the placeholder for now).

Builds clean.

[karora]

Default server now serves the full IANA set

davical.mcmillan.nz/timezones now lists 485 zones (full IANA coverage, synctoken 2026-04-17), not the 4 seen earlier. So it is data-complete: the prune guard treats it as complete (≥100) and fresh installs get the whole database. The PLACEHOLDER note in unlocalisable_strings.xml has been updated accordingly.

Remaining (lighter) question: it is the maintainer's personal server — confirm it is the intended public default (availability/load) or point the default at dedicated infra. The client + default are otherwise ready.