Your alerting stack timestamps everything in UTC, your team talks in Eastern, and the postmortem needs both to agree. The arithmetic is small but it moves: Eastern is UTC−5 in winter and UTC−4 from March 8 to November 1 in 2026, so the same 9 a.m. is 14:00 UTC in January and 13:00 UTC in July. UTC never shifts. Set the date before you set the hour — the date is what decides whether you subtract five or four. The chart below has all 24 rows if you would rather scan than type.
What People Convert EST to UTC For
Cron jobs on UTC servers
A crontab line has no opinion about daylight saving. Schedule 0 14 * * * on a UTC host and it fires at 9 a.m. Eastern all winter, then at 10 a.m. from March 8, 2026, because the wall clock in New York moved and the server's did not. Kubernetes CronJobs and GitHub Actions schedules default to UTC for the same reason. Convert the date you actually care about before you commit the line.
Incident timelines and postmortems
Pager fires, logs are stamped Z, and the retro doc says "around 3:15." Around 3:15 where? A July timeline that mixes 19:15 UTC with 3:15 p.m. Eastern reads as two separate events to anyone reviewing it a month later — they are the same instant. Pick UTC as the timeline's spine, convert every human-reported moment into it once, and note the Eastern equivalent in parentheses for the people who lived through it.
API responses and database columns
Postgres timestamptz normalizes to UTC on write, and ISO 8601 with a Z suffix travels unambiguously everywhere it goes. The trouble starts when a support ticket says the order was placed at 9 a.m. and you go looking in the table for 09:00. On a July date that row reads 13:00Z; in January the same 9 a.m. is 14:00Z. Convert first, then query.
Aviation flight planning
METARs, TAFs, and NOTAMs are published in UTC, and pilots read the trailing Z out loud as Zulu. A 1200Z departure slot is 7 a.m. in New York in January and 8 a.m. in June, which is the difference between a comfortable preflight and a missed one. Flight plans, clearance void times, and ATIS issue times all stay in Zulu precisely so the paperwork never argues with itself across a zone boundary.
Ham radio logs and contests
Every QSO goes in the log in UTC — ADIF fills QSO_DATE and TIME_ON from the Zulu clock, and contest periods open on UTC boundaries rather than anyone's local evening. A contest that starts at 0000Z Saturday begins at 7 p.m. Friday for an operator in Virginia during standard time and 8 p.m. Friday during daylight time. Log the wrong date and the checker throws out the contact.
Meeting times in global docs
A release note that says "cutover begins at 9 a.m. ET on July 22" forces every reader in Bangalore, Berlin, and São Paulo to do their own arithmetic, and some will do it with the wrong offset. Publishing 2026-07-22T13:00:00Z instead gives one number that every calendar app resolves correctly on its own. Keep the Eastern time alongside it for the New York team, but let UTC be the version of record.
Analytics and reporting day boundaries
Warehouse tables usually roll up on UTC midnight, which lands at 7 p.m. the previous evening in New York during standard time and 8 p.m. during daylight time. So a dashboard's "yesterday" actually runs from 8 p.m. two evenings ago to 8 p.m. yesterday: it quietly counts four hours your Eastern readers file under the day before, and drops last night's 8 p.m.-to-midnight entirely. Before you argue with a number, convert the boundary and check which local hours the bucket really covers. The days around March 8 and November 1, 2026 are where that check pays for itself.
How the Conversion Works
There is no fixed offset table behind this page. The converter asks the browser's IANA timezone database what America/New_York's offset was — or will be — at the exact instant you select, then applies that offset to land on UTC. It returns UTC−5 for a January date and UTC−4 for a July one, without you telling it which. UTC itself has no daylight-saving rule to apply, so it is the fixed side of every calculation. Everything runs locally; no date or time you type leaves your browser.
Frequently Asked Questions
What is 9 a.m. EST in UTC?
9 a.m. EST is 14:00 UTC, because Eastern Standard Time runs five hours behind UTC. But that answer only holds while New York is on standard time. From March 8 to November 1, 2026, the city is on EDT at UTC−4, and 9 a.m. becomes 13:00 UTC. If you are converting a summer date, 14:00 is an hour late.
Is EST always 5 hours behind UTC?
EST is, by definition, always UTC−5 — but New York is not always on EST. It observes Eastern Daylight Time at UTC−4 from the second Sunday in March to the first Sunday in November, which in 2026 means March 8 through November 1. Most people who search for "EST" mean whatever New York's clock reads today, so this page follows America/New_York and switches the abbreviation for you.
What happens to the conversion on the spring-forward date?
On March 8, 2026, New York's clock jumps from 1:59:59 a.m. EST straight to 3:00 a.m. EDT. The 2 a.m. hour does not exist locally, so there is no valid Eastern time to convert. UTC runs straight through it: 07:00 UTC that morning is 2 a.m. EST by the old offset and 3 a.m. EDT by the new one. The gap is in Eastern, not in UTC.
What about the fall-back date?
On November 1, 2026, 2 a.m. EDT rolls back to 1 a.m. EST, so the 1 o'clock hour happens twice in New York. "1:30 a.m." that morning is ambiguous on its own: the first pass is 05:30 UTC, the second is 06:30 UTC, an hour apart. UTC has no repeated hour, which is exactly why logs and incident timelines are stamped in it rather than in local time.
Does UTC ever change for daylight saving?
No. UTC has no daylight-saving rule and no seasonal adjustment anywhere on Earth; it is the reference every other zone is defined against. That is why it is the safe choice for a server clock, a database column, or a NOTAM. GMT and Zulu are commonly used as synonyms for UTC in practice, but "GMT" is also a British civil time that London leaves for BST in summer, so prefer UTC in writing.
What time is 14:00 UTC in Eastern Time?
14:00 UTC is 9 a.m. EST during standard time — subtract five hours. On a date between March 8 and November 1, 2026, subtract four instead and you get 10 a.m. EDT. The same UTC instant lands on a different Eastern wall clock depending on the season, which is why the converter above asks for a date rather than just an hour.