UTC Offset Lookup. What Is the UTC Offset for This Zone?

How the offsets in the table were derived

Nothing on this page was typed in by hand. For each zone the calculation samples all twelve months of a year and collects every distinct UTC offset it finds. That set has one or two members in practice: one means the zone never shifts, two means it does. Which of the two is standard time follows from the definition of daylight saving, which only ever moves a clock forward, so within a single zone the smaller offset is the standard one and the larger is the summer one. This holds in both hemispheres even though their summers are six months apart, because the ordering does not depend on which month a zone happens to shift in.

Because that derivation depends only on the zone's own rules, the standard and daylight columns are stable properties that will read the same next year as they do now. The now column is a different matter. It is the offset actually in force at the moment the page loads, so it flips twice a year in every zone that shifts, which is why it is computed in your browser rather than baked into the page when the site is built.

Why an abbreviation is not a safe key

Time zone abbreviations are a labelling convenience from the era of paper timetables and railway clocks, and they were never made unique across countries. The result is a set of labels with genuinely conflicting meanings, and the conflicts are not academic. CST resolves to UTC−6:00 in Chicago, UTC−5:00 in Havana, and UTC+8:00 in Shanghai. IST resolves to UTC+5:30 in Kolkata, UTC+1 in Dublin, and UTC+2 in Jerusalem. BST is UTC+1 in London and UTC+6:00 in Dhaka. An application that stores the three letters and looks them up later has stored a question, not an answer.

The International RFCs take the same position. RFC 3339, which defines the timestamp format on the modern internet, requires a numeric offset in the string itself and describes a bare abbreviation as a local offset that is unknown to the sender. The reliable form is always a number, and the reliable way to keep a schedule is to keep the IANA zone identifier alongside it.

Standard, daylight, and current are three different numbers

It is worth keeping three values apart, because collapsing them is the usual source of an hour of drift. The standard offset is what the zone uses outside summer and is the number printed in most reference tables. The daylight saving offset is what it uses inside summer, always exactly one hour further forward, though there are latter-day proposals that would change that and some zones that have experimented with half-hour and two-hour shifts. The current offset is whichever of the two is in force at the instant you asked.

Half-hour and quarter-hour zones make the arithmetic less tidy than the mental model suggests. India is UTC+5:30, Nepal is UTC+5:45, and the Chatham Islands are UTC+12:45 standard and UTC+13:45 in summer. A zone's daylight saving shift is also not always a single hour: Lord Howe Island in Australia moves by only thirty minutes, which means its two offsets are UTC+10:30 and UTC+11:00 rather than a clean hour apart.

What to store instead

If you are putting times into a database or an API, store the IANA identifier, not the offset and not the abbreviation. Asia/Kolkata means the same thing in January and July, in 2026 and in 2050, including any future rule change the IANA database records, because the meaning is resolved against the zone's rules at the moment you need it. A stored +05:30 means only that at some past instant somewhere, a clock was five and a half hours ahead of UTC, and it will quietly disagree with reality the first time a government changes its mind.

UTC Offset Lookup. What Is the UTC Offset for This Zone? — questions from actual use

What is the UTC offset for EST?

EST is UTC−5:00, and that is the number to store or transmit when a system says "EST" explicitly. Eastern Daylight Time, EDT, is UTC−4:00 and runs for roughly eight months a year. The important detail is that "EST" as an abbreviation is only correct half the year on the eastern seaboard of North America — during summer the same places are on EDT, one hour closer to UTC. If a system means a fixed offset, use −05:00 and say so; if it means the local civil time, it has to be zone-aware.

What is the UTC offset for IST?

It depends which IST you mean, and the three common ones disagree by an hour and a half. India Standard Time is UTC+5:30 with no daylight saving, Irish Standard Time is UTC+1 all year in practice, and Israel Standard Time is UTC+2 in winter and UTC+3 in summer. IST is a genuinely ambiguous label, which is why the lookup lists all three rather than guessing.

Why is the UTC offset for CST sometimes negative and sometimes positive?

Because three separate zones answer to those letters. Central Standard Time in North America is UTC−6:00, Cuba Standard Time is UTC−5:00, and China Standard Time is UTC+8:00. Chicago and Shanghai are fourteen hours apart, and both are "CST". Abbreviations were never designed to be globally unique, and nothing in RFC 3339 or ISO 8601 requires them to be.

Is the standard UTC offset the same as the current one?

Only in zones that keep a single offset all year, which is a little over a third of them. India, Japan, Singapore, China, most of West Africa, and all of Brazil hold one offset with no daylight saving, so standard and current agree there. In the roughly two thirds of populated zones that do shift for summer, the current offset equals the summer one for part of the year and the standard one for the rest.

Should I store a UTC offset or a time zone name in a database?

Store the zone name. An offset is a snapshot of one instant, and the zone it came from will change it twice a year, so a stored offset silently becomes wrong. An IANA identifier such as Asia/Kolkata or America/New_York keeps meaning across every rule change, which is why this site resolves abbreviations to those identifiers rather than to numbers.