Elm Time regional date conversion from POSIX instant

Elm Time POSIX instant does not convert to regional date

0 reputation · 19 Oct 2026, 07:40 UTC

134.6K views0

Goal

Convert a POSIX millisecond instant received through an Elm Time subscription into a regional wall-clock date for display.

Constraint

Elm 0.19.x core Time represents instants only and provides no civil date type, IANA zone database, or synchronous client-clock access. A timestamp alone does not carry an offset, so formatting it as a local date requires either a bundled zone database inside Elm or delegation to JavaScript Intl/Date through ports. Community packages vary by release, and browser Date behavior depends on the client time zone, so an incorrect choice can silently assume UTC or produce client-dependent results.

Which approach should handle regional conversion: an Elm-native zone database or JavaScript interop through ports? How should the application obtain and refresh the client offset or zone identifier without violating Elm's pure model? What checks detect incorrect results across daylight-saving transitions and future zone-rule changes?

Keep exploring this topic

Should StackBlitz unify timestamps to browser local time or keep UTC for Node preview?

StackBlitz shows client dates in local time, backend dates in UTC, and file timestamps in local time, creating inconsistency across preview, logs, and UI.

Timezone scope limits for admin grids and cron boundaries in Magento

Magento stores dates in UTC but converts to store timezone for display. Which timezone governs admin grids, reports, and cron boundaries remains version-sensitive and unclear near midnight and DST transitions.

Limits of Laravel Jetstream's Profile Form Regarding Timezone Selection

Discussing whether Laravel Jetstream should add a per‑user timezone selector to its profile form and how to implement and validate it.

Date‑time input stored as UTC despite user‑entered local offset in Jetstream profile form

Jetstream’s forms lack a timezone selector, causing date‑time inputs to be stored as UTC regardless of the user’s regional offset, leaving the handling decision unresolved.

One useful distinction: the IANA zone identifier is configuration, while the UTC offset is resolved for each instant. A POSIX timestamp alone reveals neither the user's zone nor a unique offset.

For Elm 0.19.x, a JavaScript port using Intl.DateTimeFormat avoids shipping zone rules in Elm, but requires supported Intl behavior and makes results depend on the runtime's time-zone database version. Keep port calls in Cmd/Sub and return results as messages; resolve the offset per timestamp rather than caching one client offset. If the intended zone is the browser's, obtain its identifier with Intl.DateTimeFormat().resolvedOptions().timeZone through a port; if it is a business zone, keep it in configuration.

For deterministic or offline output, an Elm-native implementation with bundled zone data is the alternative, with rule updates treated as application maintenance.

Test both sides of DST: in America/New_York, 2023-03-12T06:30Z is 01:30 at -05:00, while 07:30Z is 03:30 at -04:00. Also test both 01:30 instants around the November transition.

Elm Time POSIX instant does not convert to regional date

Goal

Constraint

0 answers

Your perspective belongs here.

1 question comment