> ## Content Index
> Fetch the complete content index at: https://stalin-pereira.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Time Zones Will Break Your Code: A Developer's Guide to Handling Dates Correctly
- URL: https://stalin-pereira.com/time-zones-will-break-your-code-a-developers-guide-to-handling-dates-correctly/
- Published: 2026-02-15T10:38:00.000Z
- Updated: 2026-10-16T19:08:20.000Z
- Description: Explaining UTC storage timezone conversion and the bugs that plague datetime handling
- Author: Stalin Pereira
- Tags: Fundamentals

**It's 3 PM Everywhere, Right?**

Wrong. And your code probably assumes it is.

## The Meeting That Never Happened

You scheduled 2 PM. They saw 10 AM. Nobody showed up.

- **Same Time** — Your server saved '2:00 PM' without context
- **Different Places** — New York, London, Tokyo all read it differently
- **Total Chaos** — Three people, three different interpretations

## Dates Are Deceptively Simple

Behind every timestamp lurks hidden complexity waiting to strike.

- **Daylight Saving** — Clocks jump forward and backward unpredictably
- **Political Zones** — Countries change timezone rules constantly
- **Edge Cases** — Midnight in one place is yesterday somewhere else

## The Old Way: Store Local Time

Saving times exactly as users enter them seems logical.

- **User Enters** — Save '3:00 PM' directly to your database
- **No Context** — Which 3 PM? New York? Paris? Sydney?
- **Silent Bugs** — Works until someone travels or moves

## The New Way: UTC Everything

One universal reference point eliminates all ambiguity.

- **Single Truth** — Store all times as UTC in your database
- **Convert Display** — Transform to user's local time only when showing
- **Always Correct** — Math works because you're comparing apples to apples

## UTC Is Your Database Language

Think of UTC as the universal translator for time.

- **Timezone Offset** — Store the user's timezone preference separately
- **Timestamp In** — Convert local time to UTC before saving
- **Timestamp Out** — Convert UTC back to local when displaying

## Bugs That Break Real Systems

These aren't hypotheticals. They happen every day.

- **Double Charges** — Payment processed twice when DST shifts
- **Missed Alerts** — Critical notifications sent at 3 AM instead of 3 PM
- **Data Gaps** — Analytics show impossible spikes or missing hours

## The Daylight Saving Trap

Twice a year, an hour appears or disappears completely.

- **Spring Forward** — 2:30 AM literally doesn't exist for one day
- **Fall Back** — 2:30 AM happens twice causing duplicate records
- **UTC Immune** — UTC never observes daylight saving changes

## Your Timezone Checklist

Follow these rules and sleep better at night.

- **Store UTC** — Never save local time in your database
- **Save Preference** — Keep user timezone as a separate field
- **Convert Late** — Only transform to local at the display layer
- **Use Libraries** — Never write custom timezone logic yourself

## Business Impact Is Real

Correct time handling affects your bottom line directly.

- **Trust** — Users rely on accurate scheduling for their lives
- **Revenue** — Billing errors from time bugs cost real money
- **Compliance** — Audit logs must show accurate timestamps

## Store UTC, Display Local

> The simplest rule that prevents the most bugs. Your database speaks UTC. Your users see their local time. Everything in between is just conversion.

---

What's the worst timezone bug you've ever encountered in production?