7 hours ago
- Date parsing is unreliable: ISO date-only strings are parsed as UTC, while other formats are parsed as local time, causing timezone shifts.
- Months are 0-indexed and Date objects are mutable, leading to silent rollover and unexpected changes.
- Timezones and DST cause off-by-one errors: getDate() vs getUTCDate() can return different days, and DST days are not always 24 hours.
- Arithmetic and duration logic are fragile: raw millisecond math assumes 24-hour days, and calendar arithmetic like 'add one month' can behave unexpectedly.
- Serialization drops timezone intent: JSON.stringify outputs UTC ISO strings, losing the original offset or wall-clock context.
- The Temporal API fixes these issues by providing explicit types (PlainDate, Instant, ZonedDateTime), immutable operations, and clear parsing rules.
- Practical rules for legacy Date code: ban ambiguous parsing, separate instant/calendar fields, use UTC for transport, never mutate shared instances, centralize date math, and test with multiple timezones.
- Adopt Temporal for new code and isolate Date behind adapters to reduce production bugs.