Common Date Parsing Pitfalls and How to Avoid Them

Date Parsing Pitfalls

Date parsing is one of the most error-prone areas in software development. Here are the most common pitfalls and how to avoid them.

1. Timezone Assumption Trap

// DANGER: Parsed as UTC in some browsers, local in others
new Date("2026-02-28");

// SAFE: Explicit timezone
new Date("2026-02-28T00:00:00Z");     // UTC
new Date("2026-02-28T00:00:00+09:00"); // JST

When you parse a date-only string like "2026-02-28", JavaScript treats it as UTC. But "2026/02/28" (with slashes) is treated as local time. This inconsistency causes bugs.

2. Month-Day Ambiguity

"01/02/2026" — is this January 2 or February 1?

Without knowing the locale, this date is ambiguous. Always use ISO 8601 format for data exchange, or specify the parsing format explicitly.

3. Two-Digit Year Cutoff

"26" — does this mean 1926 or 2026?

Different languages use different cutoff rules:

• JavaScript: 0-99 maps to 1900-1999 (Date constructor), but two-digit years in ISO strings may be interpreted differently
• Java: 80-99 → 1980-1999, 00-79 → 2000-2079 (SimpleDateFormat default)
• Python: depends on strptime implementation

4. Daylight Saving Time Gaps

# In US Eastern timezone, 2:30 AM on March 8, 2026 does not exist
# Clocks jump from 2:00 AM to 3:00 AM
datetime(2026, 3, 8, 2, 30, tzinfo=eastern)  # Ambiguous!

DST transitions create non-existent times (spring forward) and duplicate times (fall back).

5. Month Indexing

// JavaScript months are 0-indexed!
new Date(2026, 1, 28);  // February 28, not January 28
new Date(2026, 0, 28);  // January 28

// But Date.parse uses 1-indexed months
Date.parse("2026-02-28"); // February 28

6. Leap Year Edge Cases

February 29 exists only in leap years.
2024 — leap year
2026 — NOT a leap year
2100 — NOT a leap year (divisible by 100 but not 400)
2000 — leap year (divisible by 400)

7. Locale-Dependent Parsing

# This fails if system locale is not English
datetime.strptime("February 28, 2026", "%B %d, %Y")

# Month names like "February" are locale-dependent
# Use numeric formats for reliable parsing

Prevention Checklist

• Always specify timezone when parsing
• Use ISO 8601 for data interchange
• Never use locale-dependent month names in data
• Test edge cases: leap years, DST transitions, year boundaries
• Prefer parsing libraries over manual string splitting