PDT to UTC Converter — Pacific Daylight to Coordinated Universal Time

What this PDT to UTC converter does — and why there isn’t one answer

Search for “PDT to UTC converter” and almost every tool gives you a single number — usually “add 7 hours.” That number is correct for PDT, which is always UTC−7. But Pacific Time does not stay on PDT all year. From November to March it switches to PST (UTC−8). If you are converting a winter date, the correct answer is 8 hours, not 7. This tool shows all three answers simultaneously so you can see which interpretation applies before you commit.

PDT is a fixed label for the Pacific time zone during daylight saving — it is always UTC−7. PST is the winter label and is always UTC−8. UTC is a fixed offset from atomic time and never changes. So the conversion question is really: which Pacific label applies on my date? The triple-answer panel in the tool shows fixed PDT, the live Los Angeles zone, and fixed PST side by side so you can see the difference immediately.

📌 The one-sentence rule. If you mean PDT, add 7 hours. If you mean PST, add 8 hours. If you mean Los Angeles on a specific date, the tool adds 7 hours in summer and 8 hours in winter automatically — and labels the result with the correct abbreviation.

Why search results disagree — and which answer is right for you

If you have already opened two or three converters, you have probably seen contradictory claims. One tool says “PDT is 7 hours behind UTC.” Another says “Pacific Time is 8 hours behind UTC.” A third says “PDT and UTC are always 7 hours apart.” None of them is lying — they are answering different questions without saying so. Here is what each claim actually means:

The practical consequence is simple: if you copy a summer answer into a December meeting invite, you will be an hour late. If you use a winter answer for a July conversion, you will be an hour early. The triple-answer panel exists so you can see which interpretation applies to your date before you commit.

⚠ Watch out for UTC/GMT confusion. For everyday scheduling, UTC and GMT are the same. But some systems (especially older APIs and aviation systems) use “Z” or “GMT” where modern systems use “UTC.” The offset is always 0, so the conversion is identical. The difference is purely in the label.

UTC is the anchor — everything else moves around it

UTC (Coordinated Universal Time) is the modern standard for civil time. It is based on atomic clocks and is the reference point for every time zone on Earth. Unlike every other time zone, UTC never changes. It has no daylight-saving variant. It does not shift twice a year. This makes it the perfect anchor for scheduling and data storage.

When you convert PDT to UTC, you are asking: what does the clock read at the Royal Observatory in Greenwich, London, when it is 9 AM in Los Angeles during daylight saving? The answer is always 4 PM. When you convert PST to UTC, the answer is always 5 PM. The tool lets you pick either interpretation, and the triple-answer panel shows both plus the live Los Angeles zone so you never have to guess.

UTC vs GMT — what is the difference?

For everyday time conversion, UTC and GMT are the same. Both have a 0-offset from Coordinated Universal Time. UTC is the modern atomic-clock-based standard; GMT is the older astronomical term. In practice, no scheduling decision will ever be affected by the difference between UTC and GMT. This tool uses UTC because it is the precise modern standard and the one most APIs and databases prefer.

Why the literal answer and the practical answer differ

The confusion is not really about time zones — it is about the difference between an offset and an abbreviation. An offset is a fixed number of minutes from UTC. An abbreviation is a label that a specific place uses for its offset during a specific season. Two abbreviations can share an offset without ever being active at the same time.

Here is what actually happens across a calendar year:

The Los Angeles-to-UTC gap flips from 8 to 7 hours on Los Angeles’s spring-forward date, and from 7 to 8 hours on Los Angeles’s fall-back date. The literal “PDT vs UTC” comparison — 7 hours — is only a real clock match in summer, when Los Angeles is actually on PDT. In winter, the gap is 8 hours. The tool always labels the result with the correct abbreviation for the date you pick.

📌 The formula. PDT → UTC = +7 h always. PST → UTC = +8 h always. Los Angeles → UTC = +7 h in summer, +8 h in winter. The three-way compare tab shows all three at once.

Common PDT to UTC conversions at a glance

The table below covers the times people search for most. The fixed PDT column is the literal UTC−7 math. The Los Angeles column is the live-zone answer for a summer date. The fixed PST column is the literal UTC−8 math for comparison.

💡 Which column should I use? If you are scheduling with developers or storing times in a database, use the fixed PDT column for summer and fixed PST for winter, or store the UTC instant. If you are converting a specific Los Angeles time, use the Los Angeles live column — the tool will apply the correct DST offset automatically based on the date.

Your local time zone

The tool auto-detects your browser’s time zone via Intl.DateTimeFormat().resolvedOptions().timeZone. That returns the IANA name — for example America/New_York, Europe/London or Asia/Tokyo. The name appears in the green badge at the top of the converter and a live local clock runs alongside the Los Angeles, UTC and PST fixed clocks.

If your local zone isn’t one of the built-in zones, a fresh “My local time” option is added to both dropdowns. Selecting it as the source converts from wherever you are to whichever UTC interpretation you pick; the Use as source button switches the current source to your local zone in one click. That makes the tool equally usable as an “any time zone to UTC” converter or a “PDT to my time” converter.

💡 Privacy note. The detection happens entirely in your browser. The name is not transmitted anywhere — it only influences which options show up in the dropdowns on your own device.

When PDT is observed — the US daylight-saving schedule

PDT only exists during daylight saving time. The US federal schedule, unchanged since 2007, runs from the second Sunday in March to the first Sunday in November. In 2026 those dates are Sunday 8 March and Sunday 1 November.

Outside that window, Los Angeles is on PST (UTC−8), not PDT. If you enter a winter date with Los Angeles selected as the source, the tool labels the result as PST — because that is the abbreviation that actually applies on that date. There is no such thing as “PDT in December.”

If you genuinely need a UTC−7 conversion regardless of the calendar, select PDT fixed from the source dropdown. That option is always UTC−7 and never changes with the date. Similarly, select PST fixed for a guaranteed UTC−8 conversion.

⚠ Spring-forward and fall-back edge cases. On 8 March 2026 the wall-clock times between 2:00 AM and 2:59 AM do not exist in Los Angeles. On 1 November 2026 the 1:00 AM–1:59 AM window happens twice. UTC never has either problem because it never changes. The tool flags both cases so you don’t schedule a meeting for a time that never happened (or happened twice).

How to convert PDT to UTC by hand

Because the answer depends on which Pacific label applies, the hand-conversion has three branches.

Branch 1 — fixed PDT (always UTC−7)

This is what you get when you pick PDT fixed in the source dropdown. It is mathematically correct for any date and is what most APIs expect when they specify a −07:00 offset.

Branch 2 — fixed PST (always UTC−8)

This is what you get when you pick PST fixed. It is correct for winter dates and for any API that specifies a −08:00 offset.

Branch 3 — live Los Angeles (the date-dependent case)

This is the branch that catches people out. If you build a summer answer into a December meeting invite, the UTC time will be an hour late. The tool lets you switch dates and shows the correct relationship for whichever date you pick.

Finding a meeting slot that works for both zones

Because the gap is 7–8 hours, the working-hours overlap is narrow. If both sides work a standard 9 AM–5 PM day, the shared window runs from 2 PM to 5 PM Pacific in summer (which is 9 PM–12 AM UTC) or 3 PM to 5 PM Pacific in winter (which is 10 PM–1 AM UTC). The golden window — the mid-day block that is comfortable for both offices — is even narrower: 2 PM–5 PM Pacific in summer. The Golden window tab shades exactly this block across the next seven days so you can see it rather than calculate it.

The Meeting planner tab turns the same data into day cards showing the overlap hours for each of the next 7 days, with a “Best” badge on the day with the longest overlap and a suggested mid-day slot.

Real-world scenarios where this conversion matters

Scenario 1 — the developer storing timestamps

A developer in Los Angeles writes a scheduled job that runs at “9 AM Pacific.” In summer, that is 4 PM UTC. In winter, it is 5 PM UTC. If the developer stores the job as “16:00 UTC” and hard-codes it, the job will run at 8 AM Pacific in winter — an hour early. The correct approach is to store the IANA zone (America/Los_Angeles) or store the exact UTC instant for each scheduled run. The tool’s fixed PDT and fixed PST options exist for exactly this kind of precision work.

Scenario 2 — the global team standup

A team with engineers in Los Angeles and a product manager in London tries to schedule a daily standup. In summer, London is on BST (UTC+1), so the gap is 8 hours. A 2 PM Los Angeles standup is 10 PM London time. The team decides to rotate the meeting time: Los Angeles mornings (9 AM = 5 PM London) and London afternoons (4 PM = 8 AM Los Angeles). The tool’s golden-window heatmap shows exactly which hours are shared and which are not.

Scenario 3 — TV broadcasting “8/7 Central”

US prime-time TV is usually announced with an Eastern and Central feed, but the West Coast gets a separate feed. A show that airs at 8 PM Eastern is 5 PM Pacific and 12 AM UTC the next day. During winter, it is 1 AM UTC. If you are building a schedule for a live stream, always store the broadcast moment in UTC and convert to local time at display.

Scenario 4 — the API response problem

An API returns a timestamp as “2026-07-15T12:00:00-07:00” and the documentation calls it “PDT.” The offset is correct. But a consumer might read −07:00 as “MST” (which is also UTC−7) and display it as 12 PM Denver time — which happens to be correct in summer, but wrong in winter when Denver is on MDT (UTC−6). The cleanest fix is to store an explicit IANA zone (America/Los_Angeles) rather than an abbreviation, so the DST behaviour is unambiguous.

Common mistakes when converting PDT to UTC

• Assuming PDT is always 7 hours behind UTC. It is — PDT is a fixed label for UTC−7. But Pacific Time does not use PDT all year. In winter it uses PST (UTC−8), so the gap is 8 hours.
• Assuming the Pacific time zone is always 7 hours behind UTC. This is the most common error. From November to March, the gap is 8 hours. The tool labels the result as PST when appropriate.
• Using a summer answer for a winter meeting. A 4 PM UTC meeting is 9 AM PDT in summer but 8 AM PST in winter. If you build a meeting template in July and run it in December, the Pacific clock will be an hour earlier than you expect.
• Forgetting the date rollover. 5 PM PDT on Monday is 12 AM UTC on Tuesday. A converter that only shifts the clock and not the calendar produces the wrong date.
• Storing times as abbreviations. If you store “3 PM PDT” in a database, consumers will interpret it differently depending on whether they think PDT means “UTC−7” or “Pacific Time in summer.” Store the UTC instant or the IANA zone name.
• Confusing UTC and GMT. For everyday use they are the same, but some systems use “Z” or “GMT” and some use “UTC.” The offset is always 0, so the conversion is identical — but the label may vary.
• Forgetting the date rollover in UTC. 9 PM PDT on Monday is 4 AM UTC on Tuesday. If you are building a schedule, always include the date in UTC to avoid ambiguity.

Who actually needs this conversion

• Developers and DevOps teams. Scheduled jobs, cron expressions, database timestamps and API responses almost always use UTC. Converting to and from Pacific Time correctly requires knowing whether the Pacific side is on PDT or PST.
• Global teams and remote workers. Any meeting between Los Angeles and Europe, Africa or the Middle East needs the correct 7-or-8-hour offset. The golden-window heatmap makes this visual.
• Broadcast and media. A live stream scheduled at 8 PM Eastern is 5 PM Pacific and 12 AM UTC. The UTC time never changes; only the local Pacific time shifts with DST.
• Event organisers announcing a start time. A webinar at 10 AM PT needs a separate UTC line if you want international attendees to be accurate.
• Customer support teams. SLA windows published in UTC need a Pacific equivalent — and the Pacific equivalent differs in summer and winter.
• Legal and compliance teams. Deadlines specified in UTC need conversion for the Pacific counterparty, and the Pacific label must be correct for the date.
• Freelancers and contractors worldwide. Convert your own local time to a client’s UTC or Pacific time without needing to know either offset off by heart.
• Anyone confused by the 7-hour vs 8-hour discrepancy. The triple-answer panel, insight panel and three-way compare tab exist specifically to clear up this confusion.

Limitations

• The tool uses the browser’s built-in IANA time-zone database via Intl.DateTimeFormat. If a government changes its DST law and your browser has not been updated, the result may lag.
• The selectable city list covers the most common North American zones and UTC. For other zones, select My local time (if you are in that zone) or verify the offset separately and use the fixed-offset options.
• Ambiguous fall-back times are resolved by taking the first occurrence and displaying a warning. The tool warns you when this happens.
• The meeting planner and golden-window heatmap assume a standard 9 AM–5 PM working day in both zones. If your team works different hours, the shaded windows will not match your reality.
• The converter does not schedule recurring meetings or generate calendar files beyond a single-event .ics.
• Local time-zone detection relies on the browser reporting correctly. Some privacy-hardened browsers (e.g. Tor Browser) report UTC instead of the true local zone.

Frequently asked questions

Related time tools on AIToolsPros