Is EST the same as Eastern Time?

No. EST is Eastern Standard Time (UTC−5), used only from November to March. Eastern Time (ET) is the general zone name covering both EST and EDT. Using "EST" in July is incorrect.

What is the IANA time zone for Eastern Time?

`America/New_York` is the representative zone for the Eastern Time metazone. It covers New York, Toronto, Philadelphia, and dozens of other cities. The full list includes `America/Toronto`, `America/Detroit`, and `America/Indiana/Indianapolis`.

Does the converter handle integers before 1970?

Yes. The IANA database includes rules going back to the 1880s. Negative numbers are converted using historical zone rules where available.

Why does my system show "EST" in July?

That is a bug. Many software libraries and operating systems default to "EST" when they mean "ET" or local time. Fix it by using the IANA zone name `America/New_York` instead of a fixed offset string.

What happens to an integer that falls in the missing hour during spring forward?

The missing hour occurs on the second Sunday of March between 02:00 and 03:00 local. Any integer mapping to that clock time is technically invalid. The IANA database and this converter resolve it by treating it as EDT (the offset after the transition).

Where can I see the full list of cities on Eastern Time?

The cities in EST page lists every major city in the zone, from New York (population 8,804,190) to Cancún (population 888,797), along with their IANA zone names and UTC offsets.

EST Timestamp Converter

The number has no zone

Every Unix integer counts seconds since 1 January 1970 at 00:00:00 UTC. That instant is the epoch. The integer is the same in New York, London, and Tokyo. What changes is the local clock face.

Converting to Eastern Time means picking the right UTC offset for the date inside the integer. The offset flips twice a year: Eastern Standard Time runs at UTC−5, Eastern Daylight Time at UTC−4. Get the date wrong and your log, dashboard, or alert fires one hour off.

How the conversion works

Drop a Unix integer into the converter. It runs the number through the IANA time zone database using America/New_York. That database holds every official DST transition rule, year by year. The converter checks whether the instant lands before or after the spring-forward or fall-back cutover and applies the correct offset.

You do not need to know the date first. The converter reads it from the integer and picks the offset automatically.

Which offset to use

The offset depends on the date alone. The table below shows the DST transition dates from the facts:

Year	Spring forward (EST → EDT)	Fall back (EDT → EST)
2026	8 March	1 November
2027	14 March	7 November

Any instant between the second Sunday of March and the first Sunday of November needs the EDT offset (−4). Every instant outside that window needs the EST offset (−5).

Why systems store integers, not local times

Repeatability. A log entry written at 14:00:00 UTC on 1 November 2026 is unambiguous. Write the local time instead and a reader in another zone, or the same reader looking at a July log, must guess whether the offset was −4 or −5.

Unix integers go further: they strip even the UTC label. They are just a number. Every conversion tool must start with that number and a zone rule set. There is no "Eastern Time" version of a Unix integer. There is only a number and a conversion.

DST traps that break converters

The most common mistake: assuming the offset never changes. Many systems default to "EST" year-round, writing integers with a −5 offset even in July. That produces logs one hour wrong for half the year.

A correct converter checks the date. The IANA rules for America/New_York show that on 15 January 2026 the offset is −5. On 15 July 2026 the offset is −4. The converter here applies those rules.

Another trap: forgetting the transition happens at 02:00 local time. On 8 March 2026 at 01:59:59 EST, clocks jump to 03:00 EDT. The hour from 02:00 to 02:59 does not exist. An integer that maps to that missing hour is technically ambiguous. The IANA database resolves it by treating it as EDT. The converter follows the same rule.

Use it for logs, APIs, and databases

Three situations where you need this conversion:

Server logs: Most logs store UTC or Unix integers. When debugging an incident reported at a specific local time, convert the integer to Eastern Time. If the outage was reported at 09:30 Eastern, the converter tells you whether that integer lands at 09:30 EST or 09:30 EDT.
API responses: Many APIs return Unix integers in JSON payloads. A front-end displaying times to users in New York or Toronto must convert those integers to Eastern Time. Hard-coding EST breaks the display for six months of the year.
Database queries: Storing integers in a database is common for performance. When you query records created between 14:00 and 15:00 Eastern on a specific date, the conversion from integer to Eastern Time must be accurate.

For code that handles these conversions, read Eastern Time for Developers. It covers the IANA zone, the zoneinfo library, and the edge cases that trip up automated systems.