Timezone and DST bugs: a checklist for reliable scheduling

What breaks in scheduling when time zones change

When scheduling goes wrong, users don’t think “time zones.” They think the app is unreliable. The same event shows up at the wrong hour, reminders arrive early or late, or a meeting gets missed because it quietly shifted.

The most confusing failures are the ones that look correct in code. You store a date, you display a date, and tests pass. Then a real calendar crosses a time zone boundary and your “simple” conversion becomes a moving target. That’s the heart of time zone and DST bugs: offsets change, but your stored value or your conversion assumes they don’t.

The breakage usually shows up at a few predictable moments:

• DST start (the “missing hour”): a local time like 02:30 may not exist.
• DST end (the “double hour”): 01:30 can happen twice, and you pick the wrong one.
• Travel (or remote work): the same user opens the app in a different time zone.
• Server moves or container defaults: production runs in a different zone than your laptop.
• Backfills and imports: third-party data arrives with an offset, not a real zone.

A quick example: a user schedules “every day at 9:00 AM” while in New York. If you store it as “09:00 minus current offset” (instead of “9:00 in America/New_York”), it can become 8:00 AM after DST changes even though the user never asked for that.

A few rules prevent most issues:

• Decide whether the schedule is tied to a place (a time zone) or to an instant (UTC).
• Store UTC for actual moments in time, and store the IANA time zone for repeating local schedules.
• Treat “wall clock times” during DST transitions as special cases, not normal conversions.
• Add tests for DST start, DST end, and a user changing time zones.

Quick vocabulary: UTC, local time, offsets, and zones

Scheduling bugs often start with people mixing up words that sound similar. Treat these as separate concepts and name them clearly in your code and UI.

UTC (Coordinated Universal Time) is a single global clock. It doesn’t change for daylight saving time. An instant like "2026-01-16T14:30:00Z" is unambiguous anywhere in the world.

Local time is what a person sees on their clock. “9:00 AM” only makes sense when you also know where (and sometimes when) it happens.

A helpful split is:

• Instant: a specific moment in time (good for logs, payments, reminders).
• Calendar time: a date and a wall-clock time like “Monday at 9:00 AM” (good for human plans).
• Time zone: the rules that turn an instant into local time.

An offset is just a number like UTC-5. It tells you the difference from UTC right now, but it doesn’t include future or past DST rule changes.

A named zone (IANA zone) is a label like “America/New_York.” It includes the full set of rules, including when DST starts and ends.

Recurring events are the special case that trips teams up. “Every Tuesday at 9:00 AM in Paris” should usually stay at 9:00 AM Paris time, even though the corresponding UTC instant changes when DST shifts.

What to store in the database (and what not to)

Many time zone and DST bugs start with the wrong data model. If you store the “display version” of time (like a formatted string or a raw offset), you lose the information you need to make correct decisions later.

When an event is a specific moment in time (a webinar starting at one exact instant worldwide), store it as an instant in UTC. That usually means timestamps like starts_at_utc and ends_at_utc.

When an event should follow local rules (like “every Monday at 9:00 AM in New York”), store the zone ID, not just the offset. Use an IANA zone name like America/New_York, because offsets change with DST and sometimes change by law.

It also helps to store the original local date and time that a person typed. This preserves intent and makes edits predictable. For example, if someone chose “2026-03-08 09:00” in America/Los_Angeles, you want to remember that local choice even if the corresponding UTC instant shifts around DST boundaries.

A practical set of fields to consider:

• zone_id (IANA name) for any schedule tied to a place
• local_date and local_time for the user’s intended wall-clock time
• starts_at_utc (and ends_at_utc) when the event is a fixed instant
• created_offset_minutes (optional) for audit/debug, not as the source of truth
• timezone_version or a “rules updated at” timestamp (optional) if your platform supports it

Avoid storing only an offset like -0500, especially for future events. It can’t tell you which DST rule set to apply, and it will be wrong for part of the year.

For debugging, log three things together: the zone ID, the offset at the time of creation, and the computed UTC instant. Without all three, “it shifted by an hour” reports often turn into guesswork.

Choose the right model for each type of schedule

Most scheduling bugs are a mismatch: you store one kind of time, but users expect another. Before you write code, decide which model you’re building.

Model 1: Fixed instant (one real moment)

Use this when the event must happen at the same moment worldwide. Store it as an instant (UTC timestamp) and keep a time zone only for display.

A flight departing at 2026-03-10 14:00 in JFK is a fixed instant. If a traveler views it in London, the clock time changes, but the moment doesn’t.

Model 2: Floating local time (same clock time in a place)

Use this when the event is tied to a local clock, not a global moment. Store the local date, local time, and the IANA time zone (like “America/New_York”). Then resolve to an instant when you need to schedule jobs or send reminders.

A daily alarm at 07:00 is floating local time. People expect it to stay 07:00 even when DST starts or ends.

If you’re not sure which model fits, ask:

• Should the event happen at the same moment for everyone?
• Or should it happen at the same local clock time in one place?
• If a user changes their device time zone, should the event move?
• When DST shifts, should the clock time stay the same or the instant stay the same?

For invites across zones, store the organizer’s intent. If the organizer picked “9:00 AM New York time,” store that zone and local time. Each attendee can view it in their own zone, but the source rule stays clear.

Write the rule into code comments and naming. For example: startsAtUtc for fixed instants, or localStartTime + timeZoneId for floating schedules. That single decision prevents “helpful” future edits that reintroduce DST surprises.

Rendering local time without surprising people

A lot of time zone and DST bugs show up in the UI, not the database. A safe default is: keep UTC (or an instant) through your app, and convert to the viewer’s time zone at the last moment, right before display.

That “last moment” matters. If you convert earlier (for example, in an API response or inside business logic), it’s easy to double-convert later or format differently across screens. Pick one place where display formatting happens (often the frontend), and reuse the same formatter everywhere so an event looks identical in list views, detail pages, emails, and notifications.

When confusion is likely, show the zone. A bare “9:00 AM” is fine for a personal reminder, but it’s risky for shared schedules. Use formats like “9:00 AM PT” or “9:00 AM (America/Los_Angeles)” in invites, admin panels, and anything cross-team. Abbreviations can be ambiguous (CST can mean different things), so use the full zone name when stakes are higher.

If a user has no saved time zone, default to the device zone, but make it visible and easy to override. People travel. Remote teams exist. “My device guessed wrong” is a real support ticket.

Ambiguous times during fall back need special care. “1:30 AM” happens twice when clocks move back. If a user is picking a time on that date, warn them and offer a clear choice, such as “1:30 AM (before the clock change)” vs “1:30 AM (after),” or show the UTC offset.

Handling DST jumps and ambiguous times

Daylight Saving Time is where many scheduling systems get exposed. The tricky part is that the clock change can make a local time either impossible or unclear, even though it looks normal to a person.

In spring forward, one hour is skipped. In many places, 2:30 AM simply never happens on that day. If a user picks a missing time, the app needs to do something explicit instead of silently creating a wrong timestamp.

In fall back, one hour repeats. A time like 1:30 AM happens twice, once before the clock is set back and once after. That makes the local time ambiguous unless you also know which occurrence the user meant.

A policy that stays consistent

Pick a policy and apply it everywhere (create, edit, import, API).

• For missing times (spring): shift forward to the next valid time, or block and ask the user to choose.
• For repeated times (fall): pick the first occurrence (earlier) or the second (later), or ask when it matters (payments, deadlines).
• If you auto-resolve, show a small confirmation like “Adjusted to 3:00 AM due to DST.”
• Always store the user’s time zone name (like America/New_York), not just an offset.
• Record the resolution choice so the same event doesn’t change later.

After you choose, persist what you decided. For example, store “prefer earlier” vs “prefer later” for that event (some libraries call this a fold flag). Without that, a user editing the event months later might see the time shift or flip to the other occurrence.

Example: someone schedules “Nov 3, 1:30 AM” in New York. If your app always picks the first 1:30 AM, keep that decision attached to the event. If you later re-calculate from scratch, it might become the second 1:30 AM and move the meeting by an hour.

Step by step: building a scheduling flow that survives DST

Scheduling features fail when they mix up two different ideas: a fixed moment in time (an instant) and a “wall clock” time people expect locally. A reliable flow starts by choosing the model, then capturing enough information to recreate what the user meant months later.

A DST-safe scheduling flow

• Classify the event: fixed instant (one true moment) or floating local time (anchored to a zone’s clock).
• When the user picks a time, store the local date/time plus the full zone ID (for example, America/New_York), not just an offset like -05:00.
• Before saving, validate that local time against the zone rules: handle DST gaps (a time that never happens) and overlaps (a time that happens twice) using your chosen policy.
• Persist the UTC timestamp for the actual execution time, and keep the zone ID and original local fields when you need to show “what the user picked.”
• When displaying, convert from UTC into the viewer’s zone, and label it when ambiguity matters (for example, “10:00 AM New York time”).

The one rule you must choose

During a spring-forward gap, do you reject the time and ask the user to pick again, or do you automatically move it forward to the next valid minute? During a fall-back overlap, do you pick the earlier occurrence, the later one, or ask?

Pick one behavior, write it down in plain language, and keep it consistent across create, edit, and resend flows.

Common mistakes that cause DST and time zone bugs

These bugs usually start small: one shortcut in date handling that seems harmless until a user hits a DST change or opens the app from another region.

The mistakes that show up most often:

• Storing local time without the zone information. Saving 2026-03-08 09:00 without also saving the IANA zone (like America/New_York) forces you to guess later.
• Accidentally using the server’s time zone. “Parse a date, create a Date object, save it” can work in development and shift in production if the server/container zone differs.
• Adding 24 hours to mean “tomorrow.” now + 24h isn’t the same as “same local time tomorrow” during DST changes.
• Assuming offsets never change. People hardcode -0500 and move on. Offsets are the result of zone rules, not the identity of a zone, and rules can change.
• Parsing time strings that depend on locale or browser quirks. Inputs like 03/04/2026 9:00 can mean different dates depending on settings, and some browsers accept formats others reject.

A common failure: a user schedules “9:00 AM every Monday” in New York. If you store only an offset (UTC-5) instead of the zone, the event will drift by an hour after DST starts, even though the user expects it to stay at 9:00 AM.

How to write tests that don’t fail twice a year

Time zone and DST bugs often appear only in March and November (or late March and late October in Europe). The fix isn’t “more tests.” It’s the right tests, run the same way on every machine.

Make time deterministic

Remove hidden dependencies. In every test, freeze the clock and set an explicit time zone. Don’t rely on a developer laptop, CI runner, or container defaults.

A simple habit: build test dates from known UTC instants, and always declare the zone you are converting into.

Cover the tricky dates on purpose

Pick at least one US zone and one EU zone and test both the spring jump (missing hour) and fall overlap (repeated hour). Then add cases that teams often forget:

• Invalid local time (spring forward gap): a local time that doesn’t exist
• Ambiguous local time (fall back overlap): the same wall clock time mapping to two instants
• Recurring events that cross the boundary: generate 8-12 weeks and verify each occurrence
• UI formatting snapshots: verify rendered strings under different locales and zones

For example, test a weekly meeting set to 09:30 in America/New_York. When DST starts, the UTC time should change, but the displayed local time should stay 09:30. When DST ends, make sure 01:30 is handled with your chosen rule (first instance vs second) and that the rule is asserted in tests.

Include at least one realistic end-to-end test that creates, stores, and re-renders the event. That catches mismatches between database storage, API serialization, and UI formatting.

Example scenario: weekly meeting across DST for a remote team

A manager in New York sets up a weekly team meeting: every Monday at 9:00 AM. Attendees are in London and Phoenix. Everyone expects the meeting to stay at 9:00 AM New York time, even when clocks change.

Here’s what naive logic often does: the app saves the first occurrence as a UTC timestamp (say, 14:00 UTC) and then repeats by adding 7 days in UTC. That looks fine until DST changes.

• Spring forward: New York jumps from UTC-5 to UTC-4. If you keep repeating 14:00 UTC, the meeting becomes 10:00 AM in New York.
• Fall back: New York goes from UTC-4 to UTC-5. Repeating the same UTC time makes the meeting show up at 8:00 AM locally.

Correct behavior starts with storing the time zone and the rule, not just a timestamp. For a weekly meeting, save something like: zone = America/New_York, weekday = Monday, local time = 09:00, frequency = weekly. Then each occurrence is computed for that zone and converted to UTC only for delivery (calendar invites, reminders, API payloads).

London will see it shift by an hour during the weeks when the US and UK switch DST on different dates. Phoenix (no DST) may also see shifts. That’s expected when the rule is “9:00 AM New York time.”

User-facing copy prevents confusion. Show the zone where it matters and confirm the rule in plain words:

• Display: “Mon 9:00 AM (New York time)”
• Confirmation: “Repeats every Monday at 9:00 AM America/New_York. Times may differ for teammates in other time zones when daylight saving changes.”

Quick checklist before you ship a scheduling feature

Time zone and DST bugs usually show up after launch, when real users cross borders or the clocks change. A quick pre-ship check can save weeks of support and a lot of “my reminder fired at the wrong time” reports.

Data model checks

For every scheduled thing, you should be able to answer one question: is this a fixed instant, or does it follow local wall-clock rules?

• Fixed instants (one-time reminders, log timestamps): store as UTC timestamps.
• Recurring “local time” events (every Monday 9:00 in Berlin): store the local time fields plus the IANA time zone ID (for example, Europe/Berlin), not just an offset.
• Never treat a numeric offset (like -05:00) as a time zone.

DST and user-facing checks

Make DST edge cases a first-class part of product behavior.

• When a user picks a local time, detect and handle invalid times (spring forward gap) and ambiguous times (fall back repeat). Decide: block, auto-adjust, or ask.
• Tests: freeze “now” and set an explicit zone in every test. Include at least one DST start and one DST end case.
• UI and notifications: show the time zone when it matters, especially in emails, calendar invites, and reminders.

Next steps: fix existing scheduling bugs without rewriting everything

If your scheduling feature already ships, fixing time zone and DST bugs is mostly about getting visibility first, then tightening one layer at a time. You don’t need a big rewrite to stop the bleeding.

Start with a quick data audit. Look for fields that quietly mix concepts, like a column named start_time that sometimes stores UTC, sometimes stores local clock time, or strings like “2026-01-16 09:00” with no zone. Also check for duplicated fields (both utc_time and local_time) where nobody remembers which one is the source of truth.

Add lightweight logging around every conversion. When a user reports “it moved by an hour,” you want evidence of what the system decided:

• Log the user’s IANA zone (like America/New_York), not just an offset.
• Log the offset used at that instant (for DST awareness).
• Log the input value and the computed UTC result.
• Log the render path (UTC stored value -> local display).

Then fix in an order that reduces user pain fast: first rendering and confirmation screens, then storage rules, then recurrence logic.

If you inherited an AI-generated codebase, assume time handling is inconsistent across files and endpoints. Hidden conversions, library defaults, and tests that only pass outside DST weeks are common.

If you need a fast second set of eyes, FixMyMess (fixmymess.ai) is built for diagnosing and repairing AI-generated application code, including scheduling logic that breaks around DST. A short audit is often enough to pinpoint where offsets, zones, and conversions got mixed.