Lesson 5
Common Timestamp Pitfalls
Y2038, floating seconds, wrong units, and ambiguous date strings.
Even when formats look simple, timestamps fail in predictable ways. Recognizing the pattern saves hours of debugging.
Y2038 and integer limits
Classic 32-bit signed time_t overflows around 2038-01-19. Legacy embedded systems and old binaries may still use 32-bit seconds. Modern 64-bit servers mostly avoid this at storage, but exported CSVs and old clients might not.
JavaScript Date uses millisecond doubles—safe range is enormous, but very large integers pasted into parsers can still fail.
Off-by-1000 (seconds vs milliseconds)
Symptoms:
- Date near 1970-01-01 → you treated seconds as milliseconds (value too small)
- Date in the year 50000+ → you treated milliseconds as seconds
Always ask: “Is this field documented as sec or ms?”
Ambiguous local strings
2024-06-01 00:30 without timezone means different instants in Tokyo vs Toronto. Parsing it as “server local” vs “user local” vs “UTC” changes bug reports dramatically.
Daylight saving gaps and repeats
On DST transition days, local wall times can repeat or skip. Scheduling “2:30 AM local” on fall-back day may be invalid or ambiguous. Store UTC instants for alarms and billing.
String locale surprises
03/04/2024 is March 4 in US locale but 3 April in EU locale. Prefer ISO 2024-03-04 in machine-readable fields.
Key takeaway
Most timestamp bugs are unit confusion, missing timezone, or legacy width limits—not exotic math. Check those three first.