Choosing Between Host Timezone Database and Embedded IANA Database for Consistent ClojureScript Date Conversion

Goal: achieve portable, timezone‑aware date conversion when compiling ClojureScript to JavaScript targets, so that a date parsed in America/New_York yields the same instant regardless of whether the code runs in a browser, Node.js, or an embedded JS runtime.

Constraint: the built‑in js/Date API relies on the host’s timezone database, which varies across browsers and Node versions, while the cljs‑time wrapper lets developers specify IANA zone strings but requires deciding whether to embed a static IANA bundle or trust the host’s data; additionally, JVM targets can use java.time.ZonedDateTime directly, creating an API gap between platforms.

Uncertainty: choosing between a bundled IANA database (greater consistency but larger bundle and maintenance burden) and the host’s timezone data (smaller footprint but possible offset differences and DST mismatches) remains unresolved, especially when sharing code between JVM and JS builds.

Should we bundle a static IANA database to guarantee uniform offsets across all JS runtimes, or rely on the host’s timezone data and accept potential variation? How does each option affect bundle size, update frequency for DST rules, and runtime performance? What impact does the decision have on sharing timezone‑aware code between JVM and JS targets?