The time shown on a webpage is eight hours behind your computer. You agreed to meet at 3 p.m., but the other person sees a completely different time. That doesn't necessarily mean the site is broken — it could be that the time zone your browser is reading doesn't match where you actually are.
To pin down where things are going wrong, start with an online time zone check. ToDetect's time zone tool shows you the identifier your browser is currently using, your UTC offset, and related details. Compare that against your system settings and you'll usually have the problem narrowed down pretty quickly.

Your browser normally calculates local time from the time zone set in your operating system. A page can pull that information through JavaScript, so you never have to type in a city yourself.
• A complete time zone check focuses on the following — local time: the date and time your browser currently reports, which tells you whether your device clock is accurate.
• UTC time: Coordinated Universal Time, which makes it easy to compare against server-side records.
• UTC offset: the difference between local time and UTC — Beijing time, for example, is UTC+8.
• IANA time zone identifier: values like Asia/Shanghai or America/New_York, which identify the specific zone and the rules that govern it.
• DST status: whether daylight saving rules apply to the current date, which varies by region.
Of these, the IANA identifier is more useful than the UTC offset on its own. Different regions can share the same offset while following completely different DST rules.
This is one of the easiest things to misread in a browser time zone check.
JavaScript provides a getTimezoneOffset() method that returns the difference, in minutes, between UTC and local time.
For example, running this in the Shanghai time zone:
const timezone = Intl.DateTimeFormat()
.resolvedOptions().timeZone;
const offset = new Date().getTimezoneOffset();
console.log(timezone);
console.log(offset);You'll typically get: Asia/Shanghai, -480. That -480 doesn't mean your time zone is configured wrong.
The method calculates UTC minus local time. Since Shanghai is 8 hours ahead of UTC, the result comes out as -480 minutes.
So when the tool shows UTC+08:00 and JavaScript returns -480, both are describing the exact same offset — just from opposite directions.
When a page runs eight hours off your local time, the usual cause is UTC that never got converted into your time zone. Beyond that, browser settings, the time zone tied to your account, and the format of the time data itself can all play a part.
Possible causes, how they show up, and what to check:
| Possible Cause | What It Looks Like | How to Check |
|---|---|---|
| UTC never converted | The page shows server-side UTC as-is | Check whether the front end converts to the local time zone |
| Wrong system time zone | Test results don't match where you actually are | Check your device's date and time zone settings |
| Account time zone differs | Times are wrong only after signing in to a specific site | Look at the time zone preference in that site's account settings |
| Timestamps missing time zone info | Different browsers or devices show different results | Check whether the time format actually carries time zone information |
| DST handled incorrectly | A one-hour drift appears during certain seasons | Verify the DST rules for the dates in question |
Open ToDetect's time zone page and look at what it reports for your current time zone, paying particular attention to the IANA identifier and the UTC offset.
If you're physically in mainland China but the result says America/Los_Angeles, for instance, check whether your system is still set to another region's time zone.
If the result is correct but one specific site still shows the wrong time, dig into how that site renders time.
Keep in mind that a browser time zone isn't the same thing as a physical location. Anyone can manually pick a different region's time zone, so time zone data alone can't tell you where a device actually is.
Start with your operating system's date, time, and time zone settings.
On Windows, go to Settings → Time & Language → Date & time, confirm the time zone is correct, and make sure "Set time automatically" is switched on.
On macOS, open System Settings → General → Date & Time and check both the time and the time zone. On a phone, head to the date and time settings and confirm that the automatic time zone option is enabled.
If your system is configured correctly but the browser still reports something odd, try restarting the browser, or temporarily disable extensions that might be altering time data and run the check again.
For developers: store time on the server with explicit time zone information, and let the front end convert it for display. Avoid mixing UTC and local time directly.
The site may not be converting UTC properly, or the issue could sit with your account's time zone setting or the timestamp format. Compare how other sites display the same time to narrow it down.
That depends on your device settings. With the automatic time zone option switched on — and the necessary location conditions met — the system may update itself. If the time zone is set manually, you'll need to change it yourself.
Yes. Regions that observe DST shift their UTC offset during that period, so the same location can show a different offset depending on the date.
Usually not. The browser can supply the time zone on its own. Whether a specific site collects or stores any related data is something you'd need to check in its privacy policy.
The browser time zone is only a basic environment setting, but it directly affects how pages display time, whether your calendar lines up, and how easily you can trace issues through logs.
When a page's time doesn't match reality, run an online time zone check with ToDetect, verify your local time, UTC offset, and IANA identifier, then work through your system or site settings based on what you find.
Checking what the browser actually reads tends to get you to the answer faster than repeatedly nudging the clock.