Unix timestamp converter

What time is it in UTC, EST, PST and GMT?

Local time is UTC plus the zone's offset for that date. In January, 12:00 UTC is 12:00 in London (GMT), 07:00 in New York (EST, UTC−05:00) and 04:00 in Los Angeles (PST, UTC−08:00). In summer those three clocks read an hour later, so 12:00 UTC is 08:00 in New York.

The same two moments, noon UTC on 15 January and 1 July 2026, in each zone:

China, South Korea, Pakistan and India don't change their clocks, so their offsets stay at UTC+08:00, UTC+09:00, UTC+05:00 and UTC+05:30 all year. Chicago keeps US Central time, which Houston also uses.

GMT is a fixed UTC+00:00 clock, but London uses it only in winter. From late March to late October the UK is on British Summer Time, UTC+01:00 (GOV.UK's clock-change dates), so London is then an hour ahead of GMT.

How to convert a Unix timestamp to a date

A Unix timestamp counts the seconds since 00:00:00 UTC on 1 January 1970, with every day exactly 86,400 seconds long. Divide by 86,400: the whole number is the day count since 1970 and the remainder is the time of day in UTC. 1700000000 is 19,675 days and 80,000 seconds, which is 22:13:20 UTC on 14 November 2023.

Milliseconds, microseconds and nanoseconds count the same instant in smaller steps; divide by 1,000, 1,000,000 or 1,000,000,000 to get seconds. Without a stated unit, up to 11 digits are read as seconds, 12 to 14 as milliseconds, 15 to 17 as microseconds and 18 or more as nanoseconds.

That digit rule misreads millisecond counts from before 3 March 1973, which have 11 digits or fewer, and leading zeros don't add digits. Set the unit explicitly for values that close to the epoch.

Negative timestamps are before 1970, and fractions stay part of the instant: −0.5 is 1969-12-31T23:59:59.5Z.

The last two rows straddle the signed 32-bit limit: software that stores Unix time in 32 bits overflows after 03:14:07 UTC on 19 January 2038, but the count itself carries on. Dates from year 0001 to 9999 convert.

Converting ISO 8601 times and local dates

An ISO 8601 time ending in Z is UTC, and an explicit offset names the same instant another way: 2026-01-15T18:30:00+05:30 is 2026-01-15T13:00:00Z. Without Z or an offset, the time is read in the chosen zone, so keep the offset when you share a timestamp.

A local date and time becomes a timestamp through its zone's offset on that date. In autumn one hour happens twice: 01:30 on 1 November 2026 in New York is 1793511000 the first time and 1793514600 the second.

In spring a skipped time moves forward by the gap, so 01:30 on 29 March 2026 in London becomes 02:30 BST, timestamp 1774747800. To compare one local time with several cities at once, use the time zone converter.

EST, EDT, CST, PST and PDT are fixed offsets

An abbreviation names one fixed offset: EST is UTC−05:00 all year and EDT is UTC−04:00. New York switches between them, so in July "Eastern time" is EDT, and a literal EST clock reads an hour earlier than clocks in New York. Central (Chicago) and Pacific (Los Angeles) time switch the same way.

At noon UTC on the same two dates, the fixed clocks don't move:

Abbreviations also need a country. CST also means China Standard Time, UTC+08:00, in Shanghai; in the Philippines, PST is Philippine Standard Time, the UTC+08:00 clock in Manila. IST can mean India, Ireland or Israel.

NIST's official US time display shows the US zones, and its daylight-saving guidance gives the dates the clocks change.

Clock accuracy and leap seconds

The current time comes from your device's clock, shown to the second. It is not synchronized with an atomic clock, so a device that runs a few seconds fast shows a time a few seconds fast.

Unix time has no leap seconds: POSIX's time definition counts every day as 86,400 seconds. Time-zone offsets come from the IANA time zone database, which changes when governments change their rules; a fixed offset such as UTC−05:00 never follows those changes.