cljs-time parses ISO8601 offset string to wrong epoch milliseconds

Answer

The wrong epoch ms is caused by cljs-time's format/parse path, not by JavaScript Date itself in modern browsers. An inst is UTC epoch milliseconds with no zone context, so the parser must convert "2023-12-31T23:59:59-05:00" to the UTC instant 2024-01-01T04:59:59Z, epoch ms 1704067199000. If the result is off by exactly the offset, the offset was ignored or applied with the wrong sign.

Confirmed facts

• JavaScript Date.parse handles strict ISO 8601 with an explicit offset correctly in current Chrome and Firefox. An explicit offset is honored and normalized to UTC.
• cljs-time.format/parse builds a goog.date DateTime. By default goog.date interprets wall-clock fields in the browser's local time zone unless the formatter explicitly captures and applies an offset.
• Pattern letter support in cljs-time/goog.date is limited. "Z" is intended for numeric offsets, but matching of the colon form "-05:00" is inconsistent, and an unmatched offset can silently fall back to local-time interpretation.

Likely explanation

With a pattern like "yyyy-MM-dd'T'HH:mm:ssZ" the offset may not be captured for the colon form, so the fields 2023-12-31T23:59:59 are treated as local time. The resulting inst is then shifted by the local zone offset relative to UTC, which looks like an error equal to the input offset.

Steps to verify and fix for this case

1. Baseline with the JS engine. In a REPL or devtools compare:

   js/Date.parse "2023-12-31T23:59:59-05:00"

   It should equal 1704067199000 in Chrome and Firefox.
2. Test cljs-time against the same constant:

   (require '[cljs-time.format :as f] '[cljs-time.coerce :as c])
   (c/to-long (f/parse (f/formatters :date-time) "2023-12-31T23:59:59-05:00"))

3. Check pattern capture. Try the built-in :date-time formatter first, then a custom formatter with an offset pattern. Test both "-0500" and "-05:00" forms to see which is accepted.
4. Make the result zone-independent. Change the browser/OS time zone to something non-UTC, e.g. America/New_York, and repeat the parse. A correct parser returns the same epoch ms regardless of local zone.
5. If cljs-time cannot reliably express the offset form you need, use a parser that explicitly handles offsets, such as js-joda via cljs.java-time or interop, and coerce to epoch ms for inst.

One diagnostic detail that changes the recommendation: which cljs-time version and which exact formatter you are using. cljs-time is effectively unmaintained and built on goog.date, so behavior varies by version and by whether you use a custom pattern or a built-in formatter.