Integration Boundary: PureScript Date/Time Libraries ↔ JavaScript Intl API – Interoperability Question

Answer

PureScript’s Date is a thin wrapper; parse converts an ISO string to a UTC timestamp and discards the original offset. This is confirmed behavior.

Formatting that Date with Intl.DateTimeFormat without an explicit timeZone option uses the host environment’s default zone, which explains the observed drift between Node.js and browsers.

Recommended steps to round‑trip ISO strings with offsets

1. When you receive an ISO string, extract the offset manually (e.g., via a regex) before calling new Date().
2. Store the offset together with the Date in a record, e.g., { utc: date, offsetMinutes: number }.
3. For formatting, pass an explicit { timeZone: \"UTC\" } option to Intl.DateTimeFormat if you want the output to reflect the original offset consistently across runtimes.
4. If you need to display the time in a specific named zone, supply that IANA identifier (e.g., \"America/New_York\") as the timeZone option and adjust the displayed hour accordingly.

This approach preserves the original offset without requiring a change to the core Date type.

Verification

// Check that the parsed Date has lost the offset
const d = new Date(\"2023-08-01T12:00:00+02:00\");
console.log(d.getTimezoneOffset()); // runtime‑dependent, not the original +120

// Format with explicit UTC zone
new Intl.DateTimeFormat(\"en-CA\", {
  timeZone: \"UTC\",
  year: \"numeric\",
  month: \"2-digit\",
  day: \"2-digit\",
  hour: \"2-digit\",
  minute: \"2-digit\",
  hour12: false
}).format(new Date(\"2023-08-01T12:00:00+02:00\"));

Run the snippets in Node.js and a browser console; the formatted strings will match when the timeZone option is set, confirming that drift disappears.

To finalize the recommendation, please confirm whether your downstream formatting step can accept a fixed timeZone option (e.g., \"UTC\" or an IANA zone). This detail determines whether the record‑plus‑explicit‑zone pattern will meet your interop goals.