Photos Google Takeout décalées d'une ou deux heures : pourquoi
Google Takeout enregistre l'instant de prise de vue en UTC, sans fuseau. Pourquoi vos photos ressortent décalées d'une ou deux heures en France, et la parade.
Vous avez corrigé les dates de votre export Google Takeout, et c'est presque bon. Presque : une photo prise à 22h30 affiche 20h30, et une soirée du 14 juillet qui s'est terminée à une heure du matin est maintenant à cheval sur deux jours, avec les dernières photos rangées le 15. En France, le décalage est d'une heure en hiver et de deux en été.
Ce n'est pas une erreur de l'outil. C'est une information que Google ne vous a jamais rendue.
Ce que Google enregistre, et ce qu'il ne dit pas
Ouvrez n'importe quel fichier .json de l'export. Le champ photoTakenTime contient un nombre comme 1689929130. Ce sont des secondes écoulées depuis le 1er janvier 1970, comptées en UTC, le temps universel. Ce nombre désigne un instant exact, ce qui est précis mais incomplet. Il ne dit pas si vous étiez à Paris ou à Montréal au moment de déclencher.
L'EXIF, lui, fonctionne à l'envers. Il stocke une heure murale, 2023:07:21 09:25:30, sans aucun fuseau. Passer de l'un à l'autre oblige à choisir un fuseau, et l'outil que vous utilisez, quel qu'il soit, prendra celui de votre ordinateur.
En général, c'est le bon choix, parce que la plupart des gens photographient surtout chez eux. Cela se gâte pour les voyages. Une photo prise à 9 heures du matin à Tokyo peut ressortir la veille au soir si votre machine est réglée sur Paris. Les photos proches de minuit basculent au mauvais jour.
Le cas français : UTC+1 et UTC+2
La France métropolitaine est à UTC+1 en hiver et UTC+2 en été. Une photo prise le 14 juillet à 23h00 heure de Paris est enregistrée par Google comme 21h00 UTC. Un outil qui écrit cet instant dans l'EXIF avec un ordinateur réglé sur Paris obtient bien 23h00 le 14 juillet, parce qu'il applique le +2 de l'heure d'été en vigueur à cette date.
Le décalage apparaît dans deux situations. La première : l'ordinateur est réglé sur un autre fuseau, ou sur UTC, ce qui arrive sur certains PC configurés à la va-vite et sur des serveurs. Toutes les photos sont alors décalées d'une ou deux heures, et celles prises après 22h ou 23h changent de jour. La seconde : les photos ont été prises ailleurs. Vos vacances à New York ressortent avec six heures d'avance, celles de La Réunion avec deux ou trois heures de retard.
Ce que vous pouvez faire
Réglez le fuseau de votre ordinateur avant de lancer la correction, sur le lieu où la plupart de vos photos ont été prises. Sous Windows, Paramètres, Heure et langue, Date et heure. Sur Mac, Réglages Système, Général, Date et heure. Vérifiez que l'heure affichée est bien la vôtre. Ne lancez pas la correction depuis une machine réglée sur UTC.
Pour un voyage entier dans un autre fuseau, la méthode propre est de traiter ce dossier séparément avec le fuseau du voyage réglé sur l'ordinateur, puis de remettre le fuseau habituel. Avec exiftool, on peut le faire sans changer le réglage de la machine, en préfixant la commande :
TZ=America/New_York exiftool ...Il n'y a aucun moyen de retrouver le fuseau depuis le JSON seul. La seule trace de l'heure locale d'origine est l'EXIF écrit par l'appareil, s'il a survécu. C'est pourquoi il ne faut pas « corriger » les photos qui ont déjà une bonne date EXIF : leur heure locale est juste, et la remplacer par une conversion depuis l'UTC ne peut que l'abîmer.
Takeout JSON Metadata Fixer convertit chaque horodatage de façon cohérente avec le fuseau de votre ordinateur, et écrit la date EXIF et les dates de fichier en une seule passe, pour que la bibliothèque reste ordonnée. Les photos sans JSON gardent leur date EXIF telle quelle. Le lot des photos de voyage peut être traité à part, dans un dossier, avec le fuseau réglé pour l'occasion. Les 1000 premières photos sont gratuites, et tout se passe hors ligne.
Est-ce grave d'accepter un petit décalage ?
Pour beaucoup de gens, non. Un décalage de deux heures sur les photos d'un voyage ne change pas l'ordre des photos entre elles, puisqu'elles sont toutes décalées pareil. Il ne change pas non plus le mois ni l'année. Le seul effet visible est qu'une photo prise en fin de soirée peut se retrouver au lendemain, et que l'heure affichée par l'application photo ne correspond pas à votre souvenir.
Si vous voulez que ce soit exact, faites le tri par voyage avant la correction. Si vous voulez surtout que 2012 soit avant 2013, laissez le fuseau de la maison et n'y pensez plus.
Vérifier après coup
Prenez une photo dont vous connaissez l'heure, un feu d'artifice, un réveillon, un lever de soleil. Regardez sa date de prise de vue dans les Propriétés sous Windows ou dans Lire les informations sur Mac. Si elle est décalée d'une valeur ronde, une, deux, six heures, c'est un problème de fuseau ; recommencez sur ce dossier avec le bon réglage. Si elle est juste, le reste de la bibliothèque l'est aussi.
Questions fréquentes
Pourquoi l'EXIF ne stocke-t-il pas le fuseau ?
Le format EXIF de base n'a qu'une heure murale. Des balises de décalage existent dans les versions récentes, mais peu d'appareils les écrivent et peu d'applications les lisent. Les outils s'appuient donc sur l'heure murale seule.
Immich ou Synology Photos affichent une heure décalée alors que l'EXIF est juste. Pourquoi ?
Ils affichent l'heure murale de l'EXIF telle quelle, parfois avec le fuseau du serveur en plus. Vérifiez le réglage de fuseau du serveur ou de l'application, pas les fichiers.
Les vidéos ont-elles le même problème ?
Pire. Les dates du conteneur MP4 et MOV sont définies en UTC par la norme, et les lecteurs les convertissent, ou pas, selon leur humeur. Une vidéo qui semble décalée d'une ou deux heures dans un lecteur peut être juste dans un autre.