Décalage de fuseau horaire : la vérification de cohérence la moins chère du web
De toutes les vérifications de cohérence qu'un site web peut lancer, la comparaison des fuseaux horaires est la moins chère. Elle ne demande qu'un appel JavaScript et une consultation que le serveur effectue déjà. C'est aussi l'une des raisons les plus courantes pour lesquelles un compte est examiné de plus près.
Deux fuseaux horaires, deux sources
Le premier fuseau horaire vient de votre adresse. Le serveur sait d'où la requête est venue et utilise une base de géolocalisation pour associer cette adresse à une région et à son fuseau horaire. Pour une connexion à Paris, c'est Europe/Paris. Cela se passe côté serveur ; votre navigateur n'a pas son mot à dire.
Le second vient de votre navigateur. Intl.DateTimeFormat().resolvedOptions().timeZone renvoie le nom IANA avec lequel le système d'exploitation est configuré, et new Date().getTimezoneOffset() renvoie le décalage UTC actuel. Si la machine est réglée sur Berlin, la page voit Europe/Berlin, quel que soit l'endroit d'où les paquets sont venus.
Pourquoi ils divergent
Les raisons honnêtes sont les voyages, un ordinateur portable dont la région d'horloge n'a jamais été modifiée et les réseaux d'entreprise qui sortent dans un autre pays. La raison qui intéresse les sites, ce sont les proxys : un navigateur dans un pays qui utilise une adresse dans un autre, sans que personne ait pensé à l'horloge. Paris et Berlin partagent un décalage, donc le décalage seul correspondrait ; le nom IANA, lui, ne correspond pas. Les vérifications qui comparent les noms repèrent cela, et c'est pourquoi un diagnostic montre à la fois le nom du navigateur et celui de l'adresse plutôt qu'un décalage numérique.
Ce que signifie un décalage
Pris seul, rien de concluant. Beaucoup de vraies personnes le déclenchent. Mais c'est un signal bon marché, et les systèmes de notation additionnent les signaux bon marché. Un décalage, plus une adresse classée comme hébergement, plus un candidat WebRTC dans un troisième endroit, c'est une tout autre histoire qu'un décalage seul.
Les mettre d'accord
Il y a deux façons d'obtenir un résultat cohérent. Régler le fuseau horaire du système d'exploitation pour qu'il corresponde à l'adresse, ce qui fonctionne mais devient malcommode quand plusieurs profils utilisent des adresses différentes. Ou laisser le profil du navigateur remplacer le fuseau horaire qu'il signale, ce que font les navigateurs conçus à cet effet : le fuseau horaire du profil suit l'adresse avec laquelle il est lancé, de sorte que les deux noms correspondent automatiquement. La seconde approche doit aussi couvrir le décalage actuel, les passages à l'heure d'été et les chaînes de dates localisées, car un script peut comparer tout cela. Un profil qui signale Europe/Paris mais formate les dates avec un décalage de Berlin n'a fait que déplacer la contradiction.
Que chercher dans un rapport
Un diagnostic qui affiche côte à côte « Fuseau horaire d'après l'IP » et « Fuseau horaire », et les signale quand ils diffèrent, fait exactement ce que ferait la vérification d'un site. S'ils correspondent, la vérification est réussie. Sinon, vous savez maintenant lequel changer. Dans les deux cas, c'est la comparaison elle-même qui est utile, non une note qu'on y attache.
