23

Recently my automatic timezone update stopped working. (i.e. it used to work but now it doesn't)

The Troubling thing is that my Mac detects the correct location (e.g. Golden, CO), but it doesn't use this to update the timezone despite Set my timezone automatically using current location being checked. See screenshot.

Time & Date preferences showing correct location (Golden, CO), but incorrect timezone (Pacific)

Does anyone know how to fix this?

This issue now occurs with every network I have tried: work, home, airports, hotels, etc. and, I have already tried the usual set of fixes such as toggling auto timezone off and on, closing system preferences, rebooting, and repairing permissions.

OS: OS X 10.9.5 (13F1112)

System: MacBook Pro Retina, 13-in mid-2014

5
  • Bizarre. How about Maps app geolocation? Is it similarly broken? Are you installing any VPN software or able to test with the Mac tethered to an iOS device with cellular data?
    – bmike
    Sep 8, 2015 at 16:54
  • I do have a VPN installed (Junos Pulse) for work. But this issue occurs whether or not I am logged in with it. I don't have an easy way to try tethered iOS now, but if I do will comment.
    – Bryan P
    Sep 8, 2015 at 17:50
  • @bmike: Also, maps app geolocation is spot on. Just like the pin placement in time & date. Problem is not updating the timezone to match.
    – Bryan P
    Sep 10, 2015 at 3:30
  • I have exactly the same problem: The location pin updates automatically, but the time zone and clock don't. Would love a less drastic solution.
    – user203018
    Sep 24, 2016 at 19:22
  • 2
    I am still experiencing this bug in Mojave.
    – drc
    Dec 26, 2018 at 20:43

8 Answers 8

12

This just happened to me on High Sierra. Kept trying to change so that the Mac's location would automatically update the timezone. The Mac could detect where is was (both using the Maps application and the red pin in System Preferences / Date & Time / Time Zone showed the correct location) but the time zone was 'stuck' in the place where I was last week. This continued through reboots and toggling all the options in Date & Time.

Here was the fix for me. In Bash (ie, launch Terminal):

$ cd /etc
$ ls -l localt*

It should be a link to the IANA timezone database like so (assuming this Mac is near LA):

lrwxr-xr-x  1 root  wheel  45 Aug 30 17:32 localtime -> /var/db/timezone/zoneinfo/America/Los_Angeles

If it is not:

  1. Turn off the automatic time zone in System Preferences / Date & Time / Time Zone
  2. In Terminal sudo rm /etc/localtime to remove the incorrect link
  3. Reboot (localtime will be recreated)
  4. Restart automatic time zone in System Preferences / Date & Time / Time Zone

That worked for me after Googling and pulling hair for a few minutes. YMMV.

3
  • This is the route to go if you're on High Sierra.
    – zerohedge
    Nov 17, 2018 at 21:08
  • Happened to me after running Migration Assistant to set up my Mac. I had localtime symlinks for two different cities. ➜ /etc ls -l localt* lrwxr-xr-x 1 root wheel 45 Jul 8 23:54 localtime -> /var/db/timezone/zoneinfo/America/Los_Angeles lrwxr-xr-x 1 root wheel 41 Jul 8 23:52 localtime~orig -> /var/db/timezone/zoneinfo/America/Detroit. Solved it by moving the file sudo mv localtime\~orig localtime
    – johncorser
    Jul 9, 2019 at 15:06
  • Can confirm this also works on Mojave.
    – Arda
    Dec 2, 2019 at 21:05
3

Here is another work around:

  1. Launch the command line terminal (Launchpad-->Terminal)
  2. Run the following command:

    sudo ntpdate -u time.apple.com (It will ask for your password)

That's it! Your clock is now updated with Apple's time server

1
  • 3
    Nice work around. I don't see this as a true solution since I believe it only updates the time once, rather than setting up automatic updates for time. I edited the text accordingly. +1
    – Bryan P
    Oct 11, 2016 at 16:32
2

Apparently at least a few others have had this problem. See [ https://discussions.apple.com/thread/7126456 ]. The only solution found to work in that discussion is to:

Solution: Re-install the OS. (Yikes!)

Other attempts in that discussion, including a few beyond those I mention above, didn't work. A new OS install seems rather drastic/painful, so for now I will stick with the

Work around: Switch to manual timezone control.

Hopefully Apple will push a fix soon for Mavericks users, though perhaps all of the focus is on Yosemite and (soon) El Cap.

Any simpler solutions still welcome!

2

After updating to Mojave some location functions were not working despite being enabled i.e. the precise location in setting the time zone and anty location being reported in 'Find My Mac'

The problem was fixed by following advice to reset accessibility in Terminal (taken from here):

tccutil reset Accessibility

Doing so fixed the precise location feature for setting the timezone and enabled the location of my computer to be determined in 'Find My Mac' in iCloud (and in 'Find My iPhone' app in iOS) instantly.

2

@drewk's answer worked for me with the addendum that you must have location services turned on and, under the System Services menu, have the Setting Time Zone option ticked: Enabling the 'Setting Time Zone' option

1

As of today, I run Mojave, Mavericks and Lion: Mavericks and Lion are on the internal drive while Mojave is on the external one. I used to have problems in Mavericks and Lion at different points in time. The solution below takes into account the fact you don't use proxies. For Mavericks and Lion I used to have Spotlight disabled for a long time enabling it only for the macOS I'm working currently in. I don't have an explanation of why it hit Mavericks and Lion but not Mojave but I suspect it's due to the incorrect indexing of metadata across all of the bootable partitions. I turned on Spotlight for every partition I boot into turning it off for the other two (e.g., if Mavericks is current then Spotlight disabled for the others). I do it every time I re-boot to one of the 3 partitions. After that Mavericks was able to establish connection with geolocation services and the function is rock solid since then.

Maybe that helps those of you who struggle to get it working. Try running metadata processes by re-indexing your drive and make sure it's the only bootable partition or, if it's not, that Spotlight is turned only for the current bootable partition. I'd be interested to know if this suggestion rectifies this issue.

Update 12 Jan 2021

I use Squid proxy in Mavericks and Lion on port 3128 and have Spotlight enabled in both. I have no geolocation problems and to disable Spotlight indexing every time I boot from either of these partitions I put a special hidden file in the root folder of the file system.

ALTERNATIVE SOLUTION #2

MORE LIKELY TO BE THE REAL ONE.

I suddenly started to have this problem in Lion that along the course of 7 years I use it never showed it but managed to reproduce and solve. To make long story short: if the problem can't be cured by re-indexing the volume the chances are it could arise from a corrupted database cache file in one of lower system-level folders owned by a process named "locationd". The specific file I'm referring to is a database file cache.db. In Lion, there's a folder at the path /private/var/folders/zz/zyxvpxvq6csfxvn_n00000sm00006d/C. Inside the folder, you'll find clients.plist file that contains information about every process and application granted access to the geolocation services and several db files, cache.db included. The problem is that macOS doesn't update it properly if you uninstall an application that had previously used your Mac's geographical position. At the GUI level you see this as a blank icon of the uninstalled application in Security&Privacy settings of System Preferences. Changing the plist alone by deleting corresponding values doesn't lead to the auto-update of the aforementioned cache.db file but causes the OS to lose tracks of the location, hence "Your location is currently undetermined" message when you're in "Time Zone" section of "Date&Time" settings pane. The solution is to delete the cache.db file too and re-boot (the reboot is important). After that it may take some time for the system to rebuild the cache.db file but now your location becomes detectable and the red pin is positioned correctly. It now lets applications use your location seamlessly.

Beware that all above pertains to Lion. In the newer releases, the location of "locationd" files and folders may be different and so can be the database file names and their count inside the containing folder with a high probability so you have to investigate on your own: e.g., as of Mojave, the folder in question is at /private/var/db/locationd/ and inside there're hidden files with the "dat" prefix in place of cache.db. Use the following command to find the clients.plist file which would point to the enclosing folder that you can open to look inside for cache.db or similar types of files. The command is

sudo find -Ex /private/var -name *clients\.plist

Replace yourhomefolder with the actual name of your home folder. Filter the output out: you need only those entries that contain clients.plist. Look closely for the folder it's contained in.

2
  • What kind of service/proxy is listening on port 8228?
    – nohillside
    Jul 30, 2019 at 7:42
  • I updated my comment to reflect my later findings.
    – Elijah
    Mar 4, 2020 at 15:13
1

I came here because I had the same issue except on Big Sur (11.3.1) and while @drewk's answer is near-perfect, I was able to skip the reboot by doing the following:

  1. sudo rm /etc/localtime
  2. sudo ln -is /var/db/timezone/zoneinfo/America/Los_Angeles /etc/localtime

Also, this doesn't seem to address the problem permanently until Apple rolls out a fix .... however, it does allow one to create an easy alias and carry on. Something like

function update_time_zone() {
    sudo rm /etc/localtime
    sudo ln -is /var/db/timezone/zoneinfo/America/Los_Angeles /etc/localtime
}

PS. Big Sur doesn't seem to have ntpdate as mentioned in this answer

1
  • I'm in Sweden on Big Sur 11.5.2 and the Europe directory is empty everywhere for some reason, so there is nothing to link
    – OskarD90
    May 2 at 20:07
1

Short answer:

  1. Make sure that the permission for setting the time zone using location services is enabled (see @Dark Star1's answer)
  2. Golden, CO uses Mountain Time, so check what permissions the time zone info file for Mountain Time has using ls -l /var/db/timezone/zoneinfo/US/Mountain (it should be 0644 or -rw-r--r--)
  3. If permissions are not 0644, set them to 0644 using sudo chmod 0644 /var/db/timezone/zoneinfo/US/Mountain
  4. Go back into System Preferences --> Date & Time and toggle 'Set time zone automatically using current location' off then on again. The timezone should be updated successfully now.

Why this works:

macOS uses tzlinkd to manage timezone changes (not time changes, that's different).

Filtering in Console.app for errors in tzlinkd then toggling 'Set time zone automatically using current location' in system settings showed me this error (I am in Zurich but have been travelling so the timezone was different. It updated automatically all through my travels though):

tzlink failed; "/var/db/timezone/zoneinfo/Europe/Zurich" has access permissions 100755

So I googled for this error and found that the source for tzlinkd expects permissions to be 0644 for time zone info files. Indeed, all time zone files in all subfolders in /var/db/timezone/zoneinfo had permissions 0644... except Europe/Zurich, which was 0755. So I changed it to 0644 using:

sudo chmod 0644 Zurich

and toggled 'Set time zone automatically using current location'. Console.app no longer showed errors for tzlinkd, and the timezone was updated correctly.

2
  • This does not really answer the question. If you have a different question, you can ask it by clicking Ask Question. To get notified when this question gets new answers, you can follow this question. Once you have enough reputation, you can also add a bounty to draw more attention to this question. - From Review
    – Alper
    Mar 14 at 20:26
  • I reworded the text to be a direct answer to the original question.
    – SlimAlim
    Mar 15 at 15:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .