ISO 8601 to Local Time Converter

2026-09-26T15:30:45Z is 11:30:45 a.m. in New York on September 26 (UTC-04:00)

The Z at the end of an ISO 8601 timestamp means UTC (Coordinated Universal Time). New York is 4 hours behind UTC while daylight saving time is in effect (EDT, UTC-04:00, from the second Sunday of March to the first Sunday of November) and 5 hours behind the rest of the year (EST, UTC-05:00). So 15:30:45 UTC on September 26, 2026 is 11:30:45 in New York. A value that already ends in -04:00 is New York time to begin with, so nothing is subtracted from it again.

Paste any date and time text into the converter above and it works out the format, then splits the text into date, time, fraction of a second and time zone, each in its own color. The converter starts with the time zone of the device it runs on; the examples and tables on this page use New York so the numbers stay fixed. The bar under the answer lays the UTC day and the local day on one time axis, shows where the date changes, and gives the UTC range of one local day. A pasted log can be converted line by line in one go.

When a UTC timestamp has to become local time

Servers and programs usually exchange times in UTC or in ISO 8601 text with an offset, because those do not change with location. A person reading the value has to turn it into the local clock to know what actually happened.

• Reading an API or JSON response: a value such as "createdAt": "2026-09-26T15:30:45.123Z" ends in Z, so it is UTC. To match it with a customer who says the order came in at 11:30 in the morning, it has to be converted to local time.
• Reading server logs: servers set to UTC write [26/Sep/2026:15:30:45 +0000]. An outage time has to be converted before it can be lined up with other records.
• Checking email or HTTP headers: Date: Sat, 26 Sep 2026 15:30:45 GMT uses a weekday and an English month name, but it points to the same instant.
• Finding one local day of data stored in UTC: to get September 27 in New York from a UTC column, the query must run from 2026-09-27T04:00:00Z up to, but not including, 2026-09-28T04:00:00Z. The line under the bar copies that range as an SQL condition.
• Entering a setting that must be in UTC: scheduled sends, expiry times, or the basic form 20260926T153045Z that AWS request signatures use.

How it is calculated: subtract the written offset, then apply the local offset

New York time = written time − written offset + New York offset (−4 h in summer, −5 h in winter)

1. Find the time zone mark at the very end: Z (or +00:00) is UTC, +05:30 is a place 5 hours 30 minutes ahead of UTC, and -04:00 is a place 4 hours behind. With no mark, the text alone does not say which place the time belongs to.
2. Subtract the offset to get UTC: 2026-09-26T08:00:00+05:30 minus 5:30 is 02:30 UTC. A negative offset is added instead.
3. Apply the New York offset in force at that moment: 02:30 UTC minus 4 hours is 22:30 on the previous evening, September 25. In January the same UTC time would be 21:30, because the offset is -05:00 (see daylight saving rules).
4. Move the date when the clock crosses midnight: UTC 03:00 minus 4 hours is 23:00 the day before. Going the other way, 20:00 in New York plus 4 hours reaches 24:00 UTC and rolls over to the next day.

A fraction of a second does not change with the time zone, because offsets are whole minutes. The converter copies digits such as .123 or .123456789 as typed.

Reading the parts of an ISO 8601 timestamp

If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00".RFC 3339 4.3 Unknown Local Offset Convention. Section 5.6 of the same document adds that t and z may be written in lower case.

Formats the converter reads

Paste any of these as they are. Leading and trailing spaces and full-width digits are cleaned up automatically.

Long-form dates written in Korean or Japanese are read too. For work with numbers only, the Unix timestamp converter shows unit detection and the 32-bit range in more detail.

Worked examples

From 8 p.m. in New York, UTC is already on the next day

New York is 4 or 5 hours behind UTC, so the last hours of the New York evening belong to the next UTC date. In summer, every moment from 8:00 p.m. to midnight in New York already has tomorrow's UTC date; in winter, the stretch begins at 7:00 p.m. Put the other way around, one New York calendar day runs from 04:00 UTC (05:00 in winter) to the same time the next day.

Grouping data by UTC date therefore files the New York evening under the following day. To group by New York date, query the UTC range as a half-open interval. For September 27, 2026 in New York:

-- New York, 2026-09-27 (one day)
WHERE created_at >= '2026-09-27T04:00:00Z'
  AND created_at <  '2026-09-28T04:00:00Z'

Closing the range at 23:59:59 would drop a fraction such as 23:59:59.5, so "before midnight of the next day" is the safer way to write the end. On the two days a year when the clocks change, the local day is not 24 hours long: the same query for November 1, 2026 runs from 2026-11-01T04:00:00Z to 2026-11-02T05:00:00Z, which is 25 hours.

Converting to New York time in code

In a program, passing a time zone name (America/New_York) is safer than adding or subtracting hours, because the name carries the daylight saving rules for every year.

When the UTC offset representation is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time.ECMA-262 21.4.1.32 Date Time String Format. The same text is read in a different time zone depending on whether a time is attached.

US daylight saving time rules

New York uses UTC-05:00 as standard time and UTC-04:00 during daylight saving time. The dates have changed over the years, and the IANA time zone data (America/New_York) records each change. The converter follows that record, so an old timestamp is converted with the rule that applied on that date.

The current dates are set by federal law: daylight saving time starts at 2 a.m. on the second Sunday of March and ends at 2 a.m. on the first Sunday of November (15 U.S.C. 260a). A state that lies entirely within one time zone may exempt itself by state law, which is why Arizona (Phoenix) and Hawaii stay on standard time all year.

In 2026 the clocks in New York move on March 8 and November 1. On March 8, 02:00 jumps to 03:00 (at 07:00 UTC), so 2026-03-08 02:30 does not exist in New York; the converter reads it as 03:30 and says so. On November 1, 02:00 goes back to 01:00 (at 06:00 UTC), so 2026-11-01 01:30 happens twice; the converter uses the first one, 01:30 at -04:00 (05:30 UTC), and says so.

Common mistakes

• Subtracting the offset again from a -04:00 value: 2026-09-26T11:30:45-04:00 is already New York time. Subtracting 4 hours again gives a wrong 7:30 a.m.
• Treating a value without a time zone as UTC: 2026-09-26 11:30:45 carries no time zone. Find out whether the program that stored it wrote New York time or UTC, then choose the matching option under "Read values without a time zone as".
• Mixing up EST and EDT: 2026-09-26T11:30:45 EST is read as -05:00, which gives 12:30:45 in New York in September, because New York is on EDT then. Use EDT in summer and EST in winter, or a numeric offset.
• Comparing dates only: September 26 in UTC and September 26 in New York are two different days that overlap by only 19 or 20 hours. Say which time zone a daily count uses.
• Trusting abbreviations such as CST or IST: CST means US Central Standard Time (-06:00) and also China Standard Time (+08:00); IST is used by India, Ireland and Israel. The converter reads only the US abbreviations whose values RFC 5322 fixes, and asks for a numeric offset for abbreviations that several countries share. Plain "ET" and "PT" are not accepted.
• Mixing up Z and -00:00: both are UTC, but -00:00 adds that the local offset is unknown. A -0000 in an email header means the same (RFC 5322 3.3).

Limits

• Time zone calculations use the IANA data inside the browser that runs the page. Depending on its version, an offset that changed very long ago or very recently can differ.
• Week dates such as 2026-W39-6, ordinal dates such as 2026-269, and forms whose month and day order differs by country, such as 09/26/2026, are not read.
• A leap second such as 23:59:60 does not exist in Unix time, so it is counted as the next second, 0.
• The asctime form (Sat Sep 26 15:30:45 2026) is UTC in the HTTP specification, but programs often print local time with it, so it follows the setting for values without a time zone.
• Fractions of a second are accepted up to nanoseconds (9 digits). Abbreviations accepted are UTC, GMT, KST, JST, WIB, WITA, WIT, CET, CEST and the US abbreviations from RFC 5322.

Sources

• 01IETF RFC 3339: Date and Time on the Internet: Timestamps4.3 -00:00 (unknown local offset), 5.6 date-time grammar with lower-case t and z and a space separator, 5.7 leap second 60
• 02IETF RFC 5322: Internet Message Format3.3 date-time (weekday must match the date, meaning of -0000), 4.3 obsolete zone names UT, GMT and EST to PDT with their values
• 03IETF RFC 9110: HTTP Semantics, 5.6.7 Date/Time FormatsHTTP date IMF-fixdate example "Sun, 06 Nov 1994 08:49:37 GMT"; the asctime form is taken as UTC
• 04ECMA-262: 21.4.1.32 Date Time String FormatDate-only forms are UTC and date-time forms are local time. 21.4.4.41 Date.prototype.toString format
• 05Python documentation: datetime.fromisoformatFrom 3.11 reads most ISO 8601 formats, for example '2011-11-04T00:05:23Z' as UTC
• 06AWS: Signature Version 4 date handling"The time stamp must be in UTC and use the following ISO 8601 format: YYYYMMDDTHHMMSSZ"
• 07nginx: ngx_http_log_module$time_local "local time in the Common Log Format"
• 08PostgreSQL documentation: 8.5.2 Date/Time OutputISO style output example "1997-12-17 07:37:16-08"
• 09IANA Time Zone Databasenorthamerica file, America/New_York rules (1967 to now) and the zones of Phoenix and Honolulu
• 1015 U.S. Code 260a: Advancement of time or changeover datesDaylight saving time from 2 a.m. on the second Sunday of March to 2 a.m. on the first Sunday of November; state exemption for a state within one time zone

Sources checked on 2026-10-20. Time zone data is revised several times a year, and the times on screen follow the version inside the browser in use.

Frequently asked questions

Related tools