Check Your UTC Offset in 10 Seconds
Open a browser console. Type new Date().getTimezoneOffset() and press Enter. The number you see is minutes behind UTC. A negative result means you are ahead.
A result of -330 means +05:30. India, all year.
A result of 240 means -04:00. New York in July.
A result of 0 means UTC+00:00. London in January, or Reykjavík any month.
That single number is your UTC offset right this instant. It is not your time zone. It is not permanent. But it answers the question.
Offset vs Time Zone: The Critical Difference
A UTC offset is a number. It applies to one instant. It answers the question: "What is the difference between the clock where I am and UTC, right now?"
A time zone is a set of rules. It is a named geographic region with a complete history of every offset change that region has ever adopted. The IANA time zone database calls these entries by names like America/New_York or Asia/Kolkata.
Here is the distinction that matters:
- Offset: -05:00 (a fixed number)
- Time zone: America/New_York (a rulebook)
Store the number alone and you have recorded a fact about one moment. Store the zone identifier and you can compute the correct offset for any moment, past or future, including moments that have not happened yet.
This is why "I'm in UTC+2" is incomplete. It tells someone the current difference, but it does not tell them whether daylight saving time applies to you, when it starts, when it ends, or what your offset will be next month.
How Your Browser Finds Your Offset
Your computer, phone, or tablet does not ask the internet what time it is. It reads the clock from the operating system, and it reads your zone from the operating system's region settings.
The four-step lookup
The browser does this:
- Reads the current instant from the OS clock (the number of milliseconds since 1 January 1970, UTC).
- Reads your IANA zone identifier from the OS region settings.
- Looks up that zone in the compiled IANA database to find which offset applies at this instant.
- Displays the local time.
Get your zone identifier
You can see your zone identifier in any browser with:
js
Intl.DateTimeFormat().resolvedOptions().timeZone
That returns something like Europe/London or America/Chicago. This is the single most reliable way to know what your time zone is actually called.
No network, no permission
The entire operation runs locally. No permission prompt. No API call to an external server. The OS clock and the IANA database are both stored on the device.
Why Your Offset Changes with DST
Daylight saving time shifts your offset by one hour, usually twice a year. In the United Kingdom, the offset is +00:00 in winter and +01:00 in summer. Berlin runs at +01:00 in winter and +02:00 in summer. New York sits at -05:00 in January and -04:00 in July.
The spring-forward gap
When clocks move forward, an hour of local time never exists at all. In a zone that jumps from 01:59 to 03:00, the time 02:30 is not a valid reading that day.
The fall-back overlap
When clocks move backward, an hour repeats. The time 01:30 occurs twice. A bare local timestamp like "2026-11-01 01:30" cannot tell you which occurrence is meant.
Why gaps and overlaps break storage
These gaps and overlaps are exactly why a stored instant should always carry either a signed offset or a zone identifier. A raw local time is ambiguous during the overlap and invalid during the gap.
Places that never shift
Not everywhere shifts. Japan, India, most of Africa, and much of Asia keep one setting all year. Several regions have abandoned the practice in the past decade. If you live in one of those places, your offset is constant, but you still need to know it.
Fractional Offsets and Why They Exist
A surprising number of places sit at a fraction of an hour, and code that assumes whole hours will eventually meet one.
- +05:30, India (all year)
- +05:45, Nepal (all year)
- +09:30, parts of Australia (ACST, used in the Northern Territory)
- +10:30, Lord Howe Island (Australia), during DST
- +08:45, the Eucla area of Western Australia
Why fractions exist
These exist for historical and political reasons. Some are deliberate choices to align daylight hours with working hours. Some are legacies of decisions made before standard time zones were formalised.
What breaks when you ignore them
Any calculation that rounds offsets to the nearest hour will produce wrong local times for over a billion people. India alone accounts for roughly 1.4 billion of them.
How Does ISO 8601 Handle My UTC Offset?
ISO 8601 is the standard format for representing dates and times, and it handles offsets explicitly.
The format is:
YYYY-MM-DDTHH:mm:ss±hh:mm
Real examples
2026-10-01T14:30:00+05:30, India Standard Time2026-10-01T14:30:00-04:00, Eastern Daylight Time (New York in summer)2026-10-01T14:30:00Z, UTC itself
What Z means
The Z at the end stands for "Zulu" and means UTC+00:00. It is not the same as writing +00:00 in every context. Z is specifically the military designation for zero offset. In practice, they are interchangeable in ISO 8601 strings.
The T separator
The T separates the date from the time. In the 2019 revision of ISO 8601, the space is discouraged in favour of the T. When you send data between systems, always use the T.
"Is My Offset the Same as My Time Zone?" and Other Mix-Ups
"GMT and UTC are the same thing." No. GMT is a time zone, the UK zone in winter, and it observes DST by switching to BST. UTC is a time standard, not a zone. It never changes. The UK's zone in summer is UTC+1, not GMT.
"My offset tells you my time zone"
It tells you one fact about one instant. It does not tell you whether DST applies, when it starts, or what the offset will be in three months. Two places at +02:00 today, Berlin and Cairo, will diverge in October when Europe falls back and Egypt does not.
"Two places with the same offset must be in the same time zone"
False. Lagos and Berlin both run at +01:00 in winter. Lagos is in Africa/Lagos and never changes. Berlin is in Europe/Berlin and moves to +02:00 in summer. Same offset today, different rules.
"Changing my computer clock fixes time zone issues"
It changes the instant your system reports. It does not change your zone. If your zone is wrong, your timestamps will be wrong even if the clock reads correctly.
"Week 1 is the week containing January 1"
That is a different system, used in the US and Canada. ISO week 1 is the week containing the year's first Thursday. Under ISO rules, 29, 30, and 31 December can belong to week 1 of the next year.
Using Offsets Correctly in Code and Configs
Store the instant, not the local time
Use UTC for storage. Convert to local time only for display.
Store the zone identifier for future events
If you are scheduling a meeting for next March, storing "+02:00" is wrong. The offset may have changed by then. Store Europe/Berlin and compute the offset when the time comes.
Never parse a bare local time
A bare "2026-10-01 14:30" is ambiguous during the fall-back overlap and invalid during the spring-forward gap.
Let the browser handle display
Use Intl.DateTimeFormat for display. It handles the zone lookup for you. Do not try to do the arithmetic yourself.
Remember the fractional offsets
Your code should not assume offsets come in whole hours. India, Nepal, and Lord Howe Island will break that assumption.
What MySQL actually stores
MySQL converts TIMESTAMP to the session time zone on read and write. DATETIME stores the literal value without any zone. They are not the same thing.
How to Find Your Current UTC Offset
Three ways, fastest first:
- Browser console:
new Date().getTimezoneOffset(), negative means ahead of UTC. - Zone identifier:
Intl.DateTimeFormat().resolvedOptions().timeZone, gives you the IANA name. - Manual calculation: Find the current UTC time, subtract it from your local time, and write the result as ±hh:mm.
Your offset is not a permanent fact. It changes with DST, and it can change if a government alters its rules. Check it when you configure a server, schedule a cron job, or debug a timestamp that looks off by an hour.
When Does My UTC Offset Change Next?
On 1 November 2026, most of North America falls back. Europe follows on the last Sunday of October. If you are in a zone that observes DST, your offset will shift by one hour on those dates. Your scheduled jobs will run at a different UTC time than they did the week before.
The EU voted in 2019 to abolish seasonal clock changes, but member states have not agreed on which time to adopt permanently. Implementation has stalled. No end date is set.
That is the real reason the offset matters: it is the bridge between your local wall clock and the universal instant that every system actually stores. Know yours, know when it changes, and never confuse the number with the rules that produce it.