MacOS détecte l'emplacement mais ne règle pas automatiquement le fuseau horaire

À ce jour, j'utilise Mojave, Mavericks et Lion : Mavericks et Lion sont sur le disque interne tandis que Mojave est sur le disque externe. J'ai eu des problèmes avec Mavericks et Lion à différents moments. La solution ci-dessous prend en compte le fait que vous n'utilisez pas de proxies. Pour Mavericks et Lion, j'ai longtemps désactivé Spotlight pour ne l'activer que pour le MacOS sur lequel je travaille actuellement. Je n'ai pas d'explication sur la raison pour laquelle Mavericks et Lion sont touchés mais pas Mojave, mais je pense que c'est dû à une mauvaise indexation des métadonnées sur toutes les partitions amorçables. J'ai activé Spotlight pour chaque partition que je démarre en le désactivant pour les deux autres (par exemple, si Mavericks est actuel, Spotlight est désactivé pour les autres). Je le fais à chaque fois que je redémarre sur l'une des 3 partitions. Après cela, Mavericks a pu établir une connexion avec les services de géolocalisation et la fonction est solide comme un roc depuis lors.

Peut-être que cela aidera ceux d'entre vous qui ont du mal à le faire fonctionner. Essayez d'exécuter les processus de métadonnées en réindexant votre disque et assurez-vous que c'est la seule partition amorçable ou, si ce n'est pas le cas, que Spotlight est activé uniquement pour la partition amorçable actuelle. Je serais intéressé de savoir si cette suggestion rectifie ce problème.

Mise à jour du 12 janvier 2021

J'utilise un proxy Squid dans Mavericks et Lion sur le port 3128 et Spotlight est activé dans les deux cas. Je n'ai aucun problème de géolocalisation et pour désactiver l'indexation de Spotlight à chaque fois que je démarre depuis l'une ou l'autre de ces partitions, j'ai placé un fichier caché spécial dans le dossier Root du système de fichiers.

ALTERNATIVE SOLUTION #2

PLUS SUSCEPTIBLE D'ÊTRE LE VRAI.

J'ai soudainement commencé à avoir ce problème dans Lion qui, au cours des 7 années d'utilisation, ne s'était jamais manifesté mais que j'ai réussi à reproduire et à résoudre. Pour faire court : si le problème ne peut pas être résolu en réindexant le volume, il y a de fortes chances qu'il provienne d'un fichier de cache de base de données corrompu dans l'un des dossiers de niveau inférieur du système appartenant à un processus nommé "locationd". Le fichier spécifique auquel je fais référence est un fichier de base de données. cache.db . Dans Lion, il y a un dossier au chemin /private/var/folders/zz/zyxvpxvq6csfxvn_n00000sm00006d/C . Dans ce dossier, vous trouverez clients.plist qui contient des informations sur chaque processus et application ayant accès aux services de géolocalisation et plusieurs fichiers db, cache.db inclus. Le problème est que MacOS ne le met pas à jour correctement si vous désinstallez une application qui utilisait auparavant la position géographique de votre Mac. Au niveau de l'interface graphique, cela se traduit par une icône vide de l'application désinstallée dans les paramètres Sécurité et Vie privée des Préférences Système. Modifier la plist seule en supprimant les valeurs correspondantes n'entraîne pas la mise à jour automatique de l'icône susmentionnée. cache.db mais le système d'exploitation perd la trace de l'emplacement, d'où le message "Votre emplacement est actuellement indéterminé" lorsque vous êtes dans la section "Fuseau horaire" du panneau de configuration "Date&Heure". La solution consiste à supprimer le fichier cache.db aussi et redémarrez (le redémarrage est important). Après cela, il peut falloir un certain temps au système pour reconstruire le fichier cache.db mais maintenant votre emplacement devient détectable et la broche rouge est positionnée correctement. Il permet maintenant aux applications d'utiliser votre emplacement de manière transparente.

Attention, tout ce qui précède concerne le Lion. Dans les versions plus récentes, l'emplacement des fichiers et des dossiers "locationd" peut être différent et il en va de même pour les noms des fichiers de la base de données et leur nombre à l'intérieur du dossier qui les contient, avec une forte probabilité, de sorte que vous devez enquêter par vous-même : par exemple, à partir de Mojave, le dossier en question est à /private/var/db/locationd/ et à l'intérieur il y a des fichiers cachés avec le préfixe "dat" à la place de cache.db . Utilisez la commande suivante pour trouver le fichier clients.plist qui pointera vers le dossier de fermeture que vous pourrez ouvrir pour chercher à l'intérieur de celui-ci cache.db ou d'autres types de fichiers similaires. La commande est

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

Remplacer votre dossier de maison avec le nom réel de votre dossier personnel. Filtrez la sortie : vous n'avez besoin que des entrées qui contiennent clients.plist . Regardez bien le dossier dans lequel il se trouve.

Je suis venu ici parce que j'ai eu le même problème, sauf que sur Big Sur (11.3.1) et alors que Réponse de @drewk est presque parfait, j'ai pu éviter le redémarrage en faisant ce qui suit :

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

De plus, cela ne semble pas résoudre le problème de manière permanente jusqu'à ce qu'Apple propose un correctif ..... Cependant, cela permet de créer facilement un alias et de continuer. Quelque chose comme

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

PS. Big Sur ne semble pas avoir ntpdate comme mentionné dans cette réponse

Réponse courte :

1. Assurez-vous que l'autorisation de définir le fuseau horaire à l'aide des services de localisation est activée (voir La réponse de @Dark Star1 )
2. Golden, CO utilise l'heure des montagnes. Vérifiez les permissions du fichier d'information sur le fuseau horaire pour l'heure des montagnes. ls -l /var/db/timezone/zoneinfo/US/Mountain (il devrait être 0644 ou -rw-r--r-- )
3. Si les permissions ne sont pas 0644, définissez-les à 0644 en utilisant sudo chmod 0644 /var/db/timezone/zoneinfo/US/Mountain
4. Retournez dans les Préférences système --> Date et heure et désactivez puis réactivez l'option "Définir automatiquement le fuseau horaire en fonction de la position actuelle". Le fuseau horaire devrait maintenant être mis à jour avec succès.

Pourquoi ça marche :

MacOS utilise tzlinkd pour gérer les changements de fuseau horaire (pas les changements d'heure, c'est différent).

Filtrage dans Console.app pour les erreurs en tzlinkd Puis, en activant l'option "Définir automatiquement le fuseau horaire en fonction de l'emplacement actuel" dans les paramètres du système, j'ai obtenu cette erreur (je suis à Zurich, mais j'ai voyagé et le fuseau horaire était différent). Il s'est mis à jour automatiquement tout au long de mes voyages) :

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

J'ai donc cherché cette erreur sur Google et j'ai trouvé que la source de tzlinkd s'attend à ce que les permissions soient 0644 pour les fichiers d'information sur les fuseaux horaires. En effet, tous les fichiers de fuseau horaire dans tous les sous-dossiers de la section /var/db/timezone/zoneinfo avait des permissions 0644... sauf Europe/Zurich qui était de 7 h 55. Je l'ai donc changé en 0644 en utilisant :

sudo chmod 0644 Zurich

et activez l'option "Définir automatiquement le fuseau horaire en fonction de l'emplacement actuel". Console.app n'affiche plus d'erreurs pour tzlinkd et le fuseau horaire a été mis à jour correctement.