UTC vs Local Midnight -- Why Today Moves

UTC vs Local Midnight — Why "Today" Moves

UTC (Coordinated Universal Time) is the global civil-time baseline — it never changes for DST, has no offset, and is the same everywhere on Earth. Local time is UTC adjusted by a time zone offset, which itself shifts with Daylight Saving Time. This difference matters the moment your users or servers span more than one time zone.

The problem with "today"

When someone in Tokyo says "today is March 5", it may still be March 4 in New York. Both are correct — they are simply measuring "today" from different local midnights.

At UTC 14:00 on March 5:

• Tokyo (UTC+9): 23:00 March 5 — still March 5
• London (UTC+0): 14:00 March 5 — March 5
• New York (UTC-5): 09:00 March 5 — March 5
• Los Angeles (UTC-8): 06:00 March 5 — March 5
• Hawaii (UTC-10): 04:00 March 5 — March 5

But at UTC 01:00 on March 5:

• Tokyo (UTC+9): 10:00 March 5 — March 5
• London (UTC+0): 01:00 March 5 — March 5
• New York (UTC-5): 20:00 March 4 — still March 4
• Los Angeles (UTC-8): 17:00 March 4 — still March 4

This overlap means "show today's records" is ambiguous without specifying whose midnight defines "today."

Common bugs this causes

"Date changed unexpectedly": A server runs on UTC. A user in UTC-8 creates a record at 11 PM their time (7 AM UTC next day). The record is stored with tomorrow's date in UTC.

Dashboard discrepancy: A report generated at 11:30 PM Pacific shows different totals than the same report run at 12:30 AM the next morning — because one is "today" and one is "yesterday" in UTC.

Scheduled job fires at wrong time: A cron set to 0 0 * * * UTC (midnight UTC) fires at 8 PM Eastern, not midnight Eastern.

The right way to handle time in software

Rule 1 — Store as UTC instants:
Save timestamps in UTC (or as Unix epoch seconds). Never store "local time without a zone."

Rule 2 — Attach the IANA time zone ID for display:
Store the user's time zone preference (e.g. "America/New_York") and convert to local time only when rendering.

Rule 3 — For "date-only" values, store the intended time zone:
A DATE column (no time, no zone) is only meaningful relative to a known time zone. Store the zone alongside it, or document the implicit assumption.

Rule 4 — Do not assume server time zone equals user time zone:
Most cloud servers run UTC. Most users do not.

DST interaction

When clocks spring forward or fall back, the offset from UTC changes — so "midnight local" moves relative to UTC by one hour twice a year. See Daylight Saving Time Edge Cases for the full treatment.

Use the Timezone Converter to see how a specific moment appears across multiple zones and plan releases, calls, or meetings across regions with confidence.