PDT Time Converter

The model, stated exactly

The US Pacific zone is America/Los_Angeles in the IANA time-zone database. It observes Pacific Daylight Time (PDT, UTC−7) from the second Sunday in March until the first Sunday in November, and Pacific Standard Time (PST, UTC−8) the rest of the year. For 2027: PDT runs from March 14 to November 7, 2027 (daylight saving starts at 2 a.m. on March 14 and ends at 2 a.m. on November 7), and PST runs from November 1, 2026 to March 14, 2027 in the surrounding winter, resuming again on November 7, 2027 — in the previous cycle, PDT ran from March 8, 2026 to November 1, 2026. The converter never assumes the offset from the month: it tries each candidate offset (UTC−7, then UTC−8) for the entered wall time and keeps the one whose Los Angeles rendering reproduces the entered date and time exactly, reading the abbreviation from the database itself. Every output zone is then rendered from that UTC instant with Intl.DateTimeFormat. That is why the converter stays correct across the transitions, including the two awkward hours: 1 a.m. on a fall-back day occurs twice (the converter takes the first, daylight occurrence), and 2:30 a.m. on a spring-forward day does not exist at all (the converter reports it as an error instead of silently shifting it).

The worked example, line by line

Setup: Pacific date July 15, 2027, Pacific time 12:00.

Line 1 — the abbreviation. July is in the daylight-saving half, so the zone is PDT (UTC−7).

Line 2 — the UTC instant. 12:00 plus 7 hours = 19:00 UTC on July 15, 2027.

Line 3 — Los Angeles. The entered time itself: 12:00 PDT on July 15.

Line 4 — New York. EDT (UTC−4): 19:00 UTC = 15:00 EDT on July 15.

Line 5 — Chicago. CDT (UTC−5): 19:00 UTC = 14:00 CDT on July 15.

Line 6 — Denver. MDT (UTC−6): 19:00 UTC = 13:00 MDT on July 15.

Line 7 — Anchorage. AKDT (UTC−8): 19:00 UTC = 11:00 AKDT on July 15.

Line 8 — Honolulu. HST (UTC−10, no DST): 19:00 UTC = 09:00 HST on July 15.

Date-flip warnings for the far-west zones

A noon Pacific time never flips the date in any US zone — it is still the same calendar day in Honolulu at 9:00 a.m. — but the flip appears as soon as the Pacific time is early in the morning. A Pacific time of 12:00 a.m. (midnight) PDT is 9:00 p.m. on the previous day in Honolulu (HST) and 11:00 p.m. on the previous day in Anchorage (AKDT): a meeting set for "Monday at midnight Pacific" starts on Sunday evening in the far west. The same trap runs in reverse for UTC and New York: noon PDT is 19:00 UTC the same day, but 9:00 p.m. PDT is 4:00 a.m. UTC the next day and midnight in New York. Always read the date attached to each zone in the result, not just the clock time, when the Pacific time is before about 3:00 a.m. or after about 5:00 p.m.

Output · formula · meaning

Who uses this

• The scheduler writing "noon PDT" in July: enters July 15, 2027 and confirms noon PDT is 19:00 UTC, 3 p.m. in New York, and 9 a.m. in Honolulu — and that the abbreviation is actually correct for that date.
• The manager who wrote "PDT" for a January meeting: enters the January date, sees the converter label it PST, and fixes the invitation before anyone joins an hour late.
• The traveler landing in Los Angeles in July: enters July 15, 2027 and learns noon local is PDT, 19:00 UTC — not the 20:00 UTC a winter PST conversion would give.
• The remote worker across the US zones: enters one Pacific time and reads off every US zone at once, including whether Honolulu (which never shifts) has drifted an hour relative to the mainland since the last meeting.

Accuracy & limitations

The conversion is exact for the IANA time-zone database in your browser, which is the same database operating systems and airlines use. Two caveats deserve daylight. First, the converter assumes the time you enter is a Pacific wall-clock time in America/Los_Angeles — it does not cover Phoenix, which does not observe daylight saving: noon PDT in July is also noon MST in Phoenix, but noon PST in January is 1:00 p.m. MST there, so do not carry a Pacific abbreviation over to Arizona. Second, US daylight-saving rules have changed before (the current March-to-November pattern dates from 2007) and could change again by law; the converter follows whatever rules your browser's database currently carries, which is correct for scheduling today but may differ for far-future dates if the law changes. The fall-back hour (1 a.m. occurring twice) is resolved to its first, daylight occurrence, and the spring-forward gap hour is reported as an error rather than silently shifted. Error policy: empty, malformed, or impossible dates (such as February 30) and nonexistent Pacific times are reported as errors rather than calculated, so no result ever shows a rolled-over date.