EST to PST Converter

Scheduling a meeting across US coasts is the single most common reason to convert Eastern time to Pacific: someone on the East Coast has a time in mind — a 2 PM sync, an end-of-day deadline — and needs to know what that lands on for West Coast colleagues before sending the invite. Unlike converting a UTC log timestamp (where the input is already an unambiguous instant), this direction usually starts from a wall-clock time someone actually said out loud — “let’s do 2 Eastern” — which has to be interpreted as a specific moment in America/New_York before it can be translated into America/Los_Angeles’s local time.

The gap between the two coasts is a genuinely simple, stable number: 3 hours, essentially always. That stability is easy to take for granted, but it’s not automatic — it’s true specifically because Eastern and Pacific both observe US daylight saving on the identical federal schedule (springing forward the second Sunday of March, falling back the first Sunday of November), so both zones’ offsets shift by exactly the same hour, on exactly the same date, every year. Eastern is UTC-5/Pacific UTC-8 in winter, UTC-4/UTC-7 in summer — the difference between them stays 3 hours regardless of which season you’re converting for. That’s not true of every zone pair (a US-to-UK conversion’s gap actually does wobble briefly around each DST transition, since the US and UK switch on different dates — see the PST to GMT page for that case).

Working through the concrete example: 2:00 PM Eastern on July 30, 2026 converts to 11:00 AM Pacific — a clean 3-hour gap, landing comfortably inside a West Coast morning. The same 2:00 PM Eastern in January would still land on 11:00 AM Pacific, for the reason above: both zones have shifted an hour by then, so the relationship between them hasn’t moved even though each zone’s absolute UTC offset has.

Converting Eastern time to Pacific time programmatically

JavaScript has no built-in way to directly construct a Date from wall-clock digits in a specific named timezone — only from UTC or the local zone the code happens to be running in — so converting a zoned wall-clock time needs a short round-trip through UTC:

function zonedTimeToUtc(year, month, day, hour, minute, timeZone) {
  const naiveUtc = Date.UTC(year, month - 1, day, hour, minute);
  const parts = new Intl.DateTimeFormat("en-US", {
    timeZone, year: "numeric", month: "2-digit", day: "2-digit",
    hour: "2-digit", minute: "2-digit", hour12: false,
  }).formatToParts(new Date(naiveUtc));
  const get = (t) => Number(parts.find((p) => p.type === t)?.value ?? 0);
  const readBack = Date.UTC(get("year"), get("month") - 1, get("day"), get("hour") % 24, get("minute"));
  return new Date(naiveUtc - (readBack - naiveUtc));
}

const utcInstant = zonedTimeToUtc(2026, 7, 30, 14, 0, "America/New_York");
console.log(new Intl.DateTimeFormat("en-US", {
  timeZone: "America/Los_Angeles", timeStyle: "short",
}).format(utcInstant));
// "11:00 AM"

Python’s zoneinfo avoids the round trip entirely — a datetime can be constructed directly with a named zone attached:

from datetime import datetime
from zoneinfo import ZoneInfo

eastern_time = datetime(2026, 7, 30, 14, 0, tzinfo=ZoneInfo("America/New_York"))
pacific_time = eastern_time.astimezone(ZoneInfo("America/Los_Angeles"))
print(pacific_time)
# 2026-07-30 11:00:00-07:00