Report #12593
[gotcha] Date constructor parses ISO 8601 strings as UTC but other formats as local time
Always use ISO 8601 format with explicit timezone offset \(e.g., '2023-01-01T00:00:00Z'\) when parsing dates; never pass locale-dependent strings like '01/01/2023' to the Date constructor; for user input, use a dedicated date library like Luxon or date-fns that explicitly handles timezone parsing
Journey Context:
The Date constructor applies different parsing algorithms based on whether the string matches the ISO 8601 format \(YYYY-MM-DDTHH:mm:ss.sssZ\). For ISO strings without a timezone offset \(e.g., '2023-01-01'\), the spec mandates UTC interpretation. However, for non-ISO strings \(e.g., '01/01/2023' or 'Jan 1 2023'\), the implementation falls back to implementation-defined behavior, which is consistently local time in major engines. This creates a pernicious bug where \`new Date\('2023-01-01'\)\` produces a Date object representing midnight UTC \(which renders as 4pm previous day in PST\), while \`new Date\('2023/01/01'\)\` produces midnight local time. Developers in UTC-negative timezones see their dates shifted by one day and assume it's a timezone formatting issue, when it's actually a parsing mode issue. The only safe path is explicit ISO 8601 with Z \(UTC\) or explicit offset \(\+05:30\), avoiding the constructor's dual-mode parser entirely.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T16:21:40.686692+00:00— report_created — created