When the Mac Clock Is Wrong: Time Zone, Network Time, and Sleep
A Mac does not keep one piece of information about time. It keeps three, in three different places, and each of them can be wrong on its own. There is the count of seconds the machine believes have elapsed, there is the rule that turns that count into a local wall clock reading, and there is the correction the system applies in the background to stop the count drifting. A clock showing 09:14 when it should show 10:14 could be any of the three, and the fix is different in each case.
This is why switching the automatic setting off and on again works about a third of the time. It touches one of the three. When the symptom comes back the next morning, or only after the lid has been closed for a weekend, or only on one particular network, the cause was in one of the other two.
Three stores, and which one each symptom points at
The underlying count is kept in UTC. Nothing the machine displays is stored in local time, which is why changing a time zone is instant and changes no data. The rule that converts UTC into a local reading lives in a separate place again: a symbolic link at /etc/localtime points at a file named for the zone, such as a path ending in Asia/Tokyo or US/Pacific. The correction that keeps the count honest is applied by a background daemon that talks to a time server.
Sorting the symptom by when it appears points at the store involved.
| Symptom | Store involved | Where to look |
|---|---|---|
| Off by a whole number of hours, minutes correct | The zone rule | Date and Time, and Location Services |
| Correct at login, minutes of drift by evening | The background correction | The time server and the network |
| Correct until the lid is opened somewhere else | The zone rule, plus location | Location Services and Wi-Fi |
| Seconds out immediately after waking, then settles | The correction, working normally | Nothing, this is expected |
| Wrong on one network only, right on others | The network, not the Mac | Whether time traffic is allowed out |
The minutes are the giveaway. A time zone error moves the hour and leaves the minutes alone, because zones are defined as whole or half hour offsets. Drift moves the minutes. Anything where the minutes are wrong is not a zone problem, no matter how tempting the zone pane is to open first.
The daemon that keeps the count honest
The correction is not something macOS does at login and then forgets. A daemon handles it continuously, and its own manual page describes the job.
timed maintains system clock accuracy by synchronizing the clock with reference clocks via technologies like NTP. Source: the timed(8) manual page on macOS 27.0, read September 25, 2026
Two details in that manual page explain behaviour that otherwise looks like a fault. The first is that it is not meant to be driven by hand.
timed takes no arguments, and users should not launch it manually. Source: the timed(8) manual page on macOS 27.0, read September 25, 2026
The second is that it takes power into account. The manual page states that it is also aware of power and battery conditions, which is the reason a laptop running on battery may correct less eagerly than the same laptop on mains power. A machine that is always on battery and always slightly behind is not broken, and the setting that would fix it does not exist. Leaving it plugged in for an hour is a real diagnostic step, because it changes the daemon's behaviour rather than the configuration.
The server it consults is recorded in a plain file, /etc/ntp.conf, which the same manual page lists as the NTP server configuration. Reading that file shows which server the machine is actually using, which is often a regional one rather than the address a support article mentions.
Waking up is when the clock is legitimately wrong
A Mac that has been asleep has not been counting from a network reference. It has been counting from its own oscillator, which is accurate enough for a coffee break and not for a weekend. On wake the count is slightly off, and the system corrects it. The interesting part is how, because the method depends on the size of the error.
The simple network time client shipped with macOS documents the two methods and the threshold between them.
Use adjtime(2) to slew the system clock if the offset is less than 50 milliseconds. Source: the sntp(1) manual page on macOS 27.0, read September 25, 2026
Use clock_settime(2) to set the system clock if the offset is greater than 50 milliseconds, or -s is not specified. Source: the sntp(1) manual page on macOS 27.0, read September 25, 2026
Slewing means speeding the clock up or slowing it down until it catches up, so no reading is ever skipped. Setting means jumping straight to the right value. The distinction is the reason a Mac woken after a long sleep can show a visible jump, while one woken after a short sleep appears to have been right all along.
That behaviour has a practical consequence for anyone who closes the lid for days. The reading in the first seconds after wake can be wrong, and anything that records a timestamp in those seconds records the wrong one. Waiting until the network has actually connected before creating a calendar event, or committing to a repository, avoids a class of confusion that is very hard to diagnose later.
The zone follows location, and location is a chain
The zone rule can be set automatically, and Apple's own instructions name the switch.
Turn on "Set time zone automatically using your current location." Source: support.apple.com, read September 25, 2026
The switch is only the last link in a chain. For it to produce an answer the Mac has to be able to work out where it is, which needs location services enabled, and location on a Mac without cellular hardware is derived largely from the surrounding Wi-Fi. A machine on Ethernet in a server room, or on a network whose access points are not in any lookup database, can have the switch on and get nothing. The zone then stays at whatever it was last set to, usually wherever the Mac was first switched on.
Travel makes this visible in a specific way. The clock reads correctly in the old zone, every event created looks right on screen, and the whole calendar is shifted for everyone else. Setting the zone by hand is the reliable move when travelling, and the set of valid names can be listed rather than guessed. The zone is stored as that symbolic link, so a machine's real zone can be read without opening any settings pane, which is useful when the display is the thing under suspicion.
One nuance catches people who turn the switch off. With automatic zone setting disabled, a laptop will keep the zone it had, which is correct behaviour and means the clock will be wrong on arrival until someone changes it. Automatic is the better default for anyone who moves, as long as location services are actually on.
Networks that quietly prevent correction
Time synchronisation is network traffic, and networks can block it. When they do, the automatic setting stays on, reports nothing wrong, and the clock drifts anyway.
Network time uses UDP on port 123. Guest networks, hotel networks, and tightly managed corporate networks sometimes drop it, either deliberately or as a side effect of allowing only web traffic. A captive portal produces a variation on the same problem: until the portal is accepted nothing leaves the machine, and a laptop that wakes on such a network and is used immediately may never have corrected at all.
The symptom pattern is distinctive. The clock is right at home and wrong at one specific place, or right on a phone hotspot and wrong on the office network. That pattern rules out the Mac entirely, and the two things worth trying are a different time server for that region and, if the network genuinely blocks it, accepting that the correction will happen later elsewhere.
Apple's instructions cover changing the server.
Enter a network time server for your region, then click Done. Source: support.apple.com, read September 25, 2026
A VPN adds a subtlety worth knowing. A tunnel that carries all traffic will route time requests through the remote end, which usually works, and one configured to carry only certain traffic may drop them silently. Neither case changes the time zone, because the zone comes from location rather than from an address, so a Mac on a VPN terminating in another country still shows the local zone correctly. Anyone expecting the zone to follow the VPN is looking for a behaviour macOS does not have.
A virtual machine or a second operating system on the same hardware adds one more variant. Two systems that disagree about whether the hardware clock holds UTC or local time will each correct it for the other, and the visible result is a Mac that is exactly one zone offset out after every switch between them.
Proving which store is at fault
The whole diagnosis can be done by reading rather than changing, which matters because changing settings destroys the evidence.
Check the zone by reading where /etc/localtime points. Check which server the machine uses by reading /etc/ntp.conf. Check whether automatic time is on with systemsetup -getusingnetworktime, and confirm the configured server with systemsetup -getnetworktimeserver. Compare the machine's reading against a phone on cellular data, which has an independent source.
Those five readings separate the three stores in about a minute. A wrong zone with correct minutes is the first store. Correct zone with drifting minutes and automatic time on is the second, and the network is the next thing to test. Anything that only happens on wake, and settles within a minute, is the system working as documented.
While the clock is under suspicion it also has to be visible, and on a crowded menu bar it may not be. The clock sits at the right of the status strip, and a clock set to show seconds and the date is one of the widest items there. Collapsing the icons that do not need to be seen keeps it readable without shortening it, and whether a collapsed item can still be clicked directly is set out on the feature list.
What to change first
Read the minutes before touching anything: whole hours wrong is the zone, minutes wrong is the correction. If it is the zone, check location services before the Date and Time pane, and if it is the correction, test the same Mac on a different network before changing the server. If the real annoyance is that the clock is squeezed into a full strip, a tool such as Koffret sorts that, and the comparison page covers how it differs from simply hiding items.
Frequently asked questions
Why is the clock right on the phone and wrong on the Mac on the same Wi-Fi?
A phone on cellular data gets time from the mobile network, which no local firewall can block. A Mac depends on reaching a time server over the network it is attached to, and a guest or corporate network may not allow that traffic out. Testing the Mac on a phone hotspot separates the two in one step.
Does the Mac clock need to be corrected by hand if automatic time is on?
Normally no, and doing it by hand hides the real problem. The exception is a network that blocks time traffic, where automatic will report no error and correct nothing. Setting the time manually there is a temporary measure and it will drift again, so the network is the thing to fix.
Why is the clock a few seconds out right after waking the Mac?
Because the machine counted on its own oscillator while asleep and is now catching up. macOS slews small offsets gradually rather than jumping, so a short delay before the reading settles is documented behaviour rather than a fault. A large offset after a long sleep is set in one step instead, which is why that one looks like a jump.
Can the time zone be set without turning on location services?
Yes. Turning off automatic zone setting and choosing the zone from the list is reliable and needs no location data. The trade is that a laptop will keep that zone after travelling, so it has to be changed by hand on arrival. Machines that never move are better off with the switch off.
Why does a dual boot or virtual machine setup keep breaking the clock?
Because the two systems can disagree about whether the shared hardware clock stores UTC or local time. Each one then corrects it for its own assumption, and the other sees an offset exactly the size of the time zone. Configuring both to treat the hardware clock as UTC removes the conflict.