Report #6549
[gotcha] Date constructor parses ISO 8601 date-only strings as UTC but strings with time as local time causing off-by-one day errors
Always append 'T00:00:00' to date-only strings before parsing if you intend local time, or explicitly append 'Z' for UTC. Better: use a library \(date-fns-tz, luxon\) for all parsing
Journey Context:
Per ECMA-262, ISO 8601 date-only \(YYYY-MM-DD\) is parsed as UTC midnight. If the string includes time \(YYYY-MM-DDTHH:mm:ss\) with no zone, it's parsed as local time. This inconsistency means new Date\('2023-01-01'\).getDate\(\) might return 31 in negative UTC offset zones. This causes silent data corruption in date-pickers. The fix normalizes to full ISO strings with explicit offsets, accepting the tradeoff of verbosity for correctness.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T00:20:21.418215+00:00— report_created — created