Technical Anshu
Tutorials Blog
🕐 Time Zone Truth

Ubuntu Time Zone Correct but Clock Still Wrong What to Check

You have set the zone three times. It says Asia/Kolkata, clear as day - and the clock is still wrong. That is because the time zone never contained your time in the first place. It only decides how a correct UTC time is displayed. When the display conversion is right and the result is wrong, the input is lying.

✍️ Technical Anshu🐧 Ubuntu⏱️ 6 minute read
🎥 Watch the full video - every Ubuntu time fix shown live, step by step

Think of it as arithmetic Ubuntu does for you: Local time = Universal time + zone offset. The zone setting is only the offset. If Universal time itself is wrong - because the hardware clock fed Ubuntu a bad starting value, or sync never corrected it - then perfect zone settings faithfully produce a wrong local time. This guide teaches the one-minute read that tells you whether to fix the zone, the hardware clock's meaning, or the sync - instead of re-setting the zone a fourth time.

Terminal - right zone, wrong answer: read the Universal time line
$ timedatectl Local time: Sun 2026-10-25 07:44:03 IST Universal time: Sun 2026-10-25 02:14:03 UTC RTC time: Sun 2026-10-25 02:14:03 Time zone: Asia/Kolkata (IST, +0530) System clock synchronized: yes NTP service: active RTC in local TZ: no
The phone says 10:14 in Kolkata. The zone is right (+0530) and sync says yes - but Universal time reads 02:14 when it should read 04:44. The input is wrong, so the display is wrong. Example values.
1

Do the Arithmetic - Which Line Is Lying

  1. Run timedatectl and find your phone's time - that is your truth for the next minute
  2. Check Universal time first: for India it should be your local time minus 5:30. If this line is wrong, the zone is innocent
  3. Check Local time: it should equal Universal plus your offset exactly. If the maths between the two lines is right but both are shifted, the whole clock is shifted
  4. Check RTC time: on a standard setup it equals Universal time. If RTC equals your local wall time instead, the hardware clock is being stored as local time - the dual-boot pattern

Three lines, one minute, and the fault has a name. Everything after this is just applying its fix.

2

Actually Change the Zone - and Prove It Changed

Sometimes the zone really is the fault - it shows the wrong city, or a travel laptop never came home. Do it verifiably:

  1. GUI: Settings, then Date & Time - unlock, and pick your region on the map or list
  2. Terminal: find the exact name with timedatectl list-timezones, then set it with sudo timedatectl set-timezone Asia/Kolkata
  3. Re-run timedatectl and confirm the Time zone line changed and Local time now matches your phone
  4. The setting lives in the /etc/localtime link - if a tool keeps reverting it, something else (a container, a config manager) owns that file

If the zone line was already right, do not perform this step as a ritual - it changes nothing, which is exactly the frustration that brought you here.

3

Wrong by Exactly the Zone Offset - It Is the RTC Convention

  1. If Local time is off by exactly +5:30 or -5:30 (your zone offset), the conversion maths is fine and the RTC's meaning is disputed
  2. That is the dual-boot signature: Windows stores local time in the hardware clock, Ubuntu reads it as UTC
  3. The RTC in local TZ line in timedatectl tells you which assumption Ubuntu is currently using
  4. The cure is one agreed convention - timedatectl set-local-rtc 1 on Ubuntu's side, or RealTimeIsUniversal in Windows - covered in their own guides

Setting the zone again in this state is like re-labelling a thermometer - the reading shifts on paper, the temperature of the fault does not change.

4

Wrong by Random Minutes - It Is Sync or Hardware

  1. An error of odd minutes that grows over days means nobody is correcting the clock
  2. Read the System clock synchronized line: if it says no, work the sync fault - timedatectl set-ntp true, the timesyncd service, and the network's UDP 123 path
  3. If it says yes and the time is freshly wrong after every full shutdown, the hardware clock loses time while off - the CMOS battery pattern, worst on older machines
  4. A quick manual set with sudo timedatectl set-time "10:14:00" proves the display path works, but it is a test, not a fix - an uncorrected cause will drift it wrong again

Random error sizes are good news, in a way: they rule the zone completely out of the investigation.

5

One App Shows a Different Time - the Rare Last Case

Occasionally the system clock is right and a single program disagrees:

  1. First confirm the system truth with date in a terminal against your phone
  2. A virtual machine or container has its own clock entirely - its wrong time says nothing about your host's settings
  3. Some apps read a zone from their own profile or from the account you signed into - a calendar showing another city's hours is usually this
  4. Browsers use the system clock for certificate checks, so a browser crying about invalid certificates while the clock "looks right" deserves a timedatectl read, not a browser reinstall

Nine times out of ten the app is the messenger. Shoot it last.

🕐 The sentence to remember: the zone converts, it does not correct. If Universal time is wrong, no zone setting on Earth can make Local time right - fix the input, not the label.

Watch the Complete Video Guide

The video runs this exact three-line diagnosis on a live machine - watch the Universal time line catch the real culprit.

Watch Full Video
❓ Common Questions (FAQ)

Why does changing the time zone not fix my clock?

Because the zone only adds an offset to Universal time for display. If Universal time itself is wrong - from a misread hardware clock or failed sync - the displayed time stays wrong by the same amount under every zone. Read the Universal time line in timedatectl to see it directly.

How do I know if my problem is the zone at all?

If the Time zone line in timedatectl names the wrong place, it is the zone. If it names your place and the time is still off, compute: Local minus Universal should equal your offset. When that maths holds but both are shifted from real time, your fault is the RTC convention, sync, or the battery - never the zone.

Can a wrong clock break websites even when it looks almost right?

Yes. Secure connections check certificate dates against your clock. A clock off by months makes valid sites look expired or not-yet-valid, and sign-ins with time-based codes fail. If browsers complain about certificates on many sites at once, check timedatectl before touching the browser.

This guide is based on the Technical Anshu Ubuntu time fix video - stuck on any step, ask in the video comments and you will get an answer.