Français

Outils de développement · Convertisseur d'horodatage Unix

Comment le navigateur convertit une époque en heure locale avec Date et Intl

· Comment ça marche

horodatages Validation javascript API du navigateur

Une époque entrant dans un navigateur et émergeant sous forme de lectures UTC et d'horloge locale
Illustration vectorielle originale de ToolAcre

Un convertisseur de navigateur ne dispose pas de sa propre base de données d'horloge de serveur ou de fuseau horaire ; il s'appuie sur l'objet Date et l'API Intl soutenue par votre système d'exploitation. Cet article explique ce pipeline et ses limites.

D'où le navigateur obtient-il le « local » ? — la même époque affichée différemment sur un ordinateur portable et un téléphone dans la même pièce

Deux appareils côte à côte peuvent afficher une époque différemment lorsque leurs zones locales configurées diffèrent. L'entier ne change pas entre l'ordinateur portable et le téléphone ; chaque navigateur construit le même instant, puis fournit des champs de calendrier local pour son propre environnement. « Local » décrit donc le lecteur, et non une propriété portée à l'intérieur de l'époque.

ToolAcre rend cette dépendance visible en étiquetant la ligne locale avec `Intl.DateTimeFormat().resolvedOptions().timeZone`. Une capture d'écran indiquant une heure et un journal du serveur indiquant une autre peuvent tous deux être des lectures fidèles. Comparez d'abord leurs lignes UTC ; la sortie UTC correspondante montre que la présentation, plutôt que l'instant sous-jacent, diffère.

La date prend des millisecondes : le contrat du constructeur, pourquoi les secondes doivent être multipliées par mille et la plage que la date peut représenter

JavaScript `Date` reçoit les millisecondes de l'époque. `fromEpoch` de ToolAcre multiplie une entrée en secondes par 1,000 et laisse une entrée en millisecondes inchangée avant de construire l'objet. Cette conversion est explicite car passer 1,717,243,200 directement à `new Date` signifierait environ vingt jours après 1970, et non juin 2024.

L'implémentation rejette un nombre non fini et toute valeur interprétée au-delà de ±8.64×10¹⁵ millisecondes avant le formatage. Cette limite provient de la plage de dates nommée dans la source, et non de l'horloge d'une base de données ou du système d'exploitation. Changer le sélecteur peut déplacer une valeur au-delà de la limite, donc une erreur vous indique également quelle unité a été appliquée.

Accesseurs UTC et accesseurs locaux – getUTCHours et getHours, et comment le moteur applique le décalage

ToolAcre n'extrait pas les champs avec `getUTCHours` et `getHours` ; le libellé de l’accesseur du plan est plus spécifique que l’implémentation. Il demande à `Intl.DateTimeFormat` de formater la date une fois avec `timeZone: "UTC"` et une fois sans remplacement de zone. Les deux appels reçoivent la même valeur en millisecondes, donc aucun des deux ne peut déplacer l'événement lui-même.

Cette distinction est importante lors du débogage. Si les lignes des secondes et des millisecondes concordent avec le producteur mais que l'étiquette locale vous surprend, inspectez la zone du navigateur plutôt que d'ajouter des heures à l'époque. L'arithmétique de décalage manuel créerait un instant différent, puis permettrait au formateur d'appliquer à nouveau les règles locales, produisant l'erreur classique de double ajustement.

UTC et le formatage local demandent au moteur deux lectures d'une date

Le convertisseur peut prouver qu'il demande au navigateur `resolvedOptions().timeZone` ; il ne peut pas prouver si un moteur particulier a obtenu chaque règle de fuseau horaire à partir du système d'exploitation, des données groupées ou d'une autre couche de plate-forme. La source traite délibérément ces machines comme la responsabilité du moteur et revient à l'expression « heure locale » si la requête de zone échoue.

Cette limite de preuve est utile. Une zone nommée dans le résultat identifie le choix actuel du navigateur, mais il ne s'agit pas d'un rapport de version pour une base de données de fuseaux horaires. Si deux environnements ne sont pas d'accord sur une ancienne date, enregistrez le navigateur, le système d'exploitation et la zone affichée. Le convertisseur fournit l'observation ; il ne diagnostique pas le paquet de données derrière Intl.

Le navigateur signale une zone locale, tandis que sa source de règle reste un détail d'implémentation

Pour la ligne ISO, `toISOString()` fournit une chaîne UTC avec un Z final et trois chiffres fractionnaires. L'UTC et les lignes locales lisibles par l'homme utilisent un formateur anglais de Grande-Bretagne avec l'année numérique, le mois abrégé, le jour à deux chiffres et une horloge 24 heures. Le formateur demande également `shortOffset`, faisant du décalage applicable une partie de chaque ligne rendue.

Ces choix expliquent pourquoi la copie de `Date.toString()` depuis une console n'est pas une preuve équivalente. Sa prose exacte dépend des paramètres régionaux et ne fait pas partie du contrat de sortie de cet outil. ToolAcre corrige ses options d'affichage, tout en permettant à la zone locale réelle de varier. Copiez la valeur ISO lorsqu'un autre système a besoin d'une comparaison stable et lisible par machine.

Exemple concret : une époque, trois sorties – une chaîne ISO UTC, une heure formatée localement et le décalage en minutes à partir de getTimezoneOffset

Entrez 1,717,243,200 et choisissez les secondes. La multiplication produit 1,717,243,200,000 millisecondes, que les tests établissent comme `2024-06-01T12:00:00.000Z`. La ligne UTC formate cet instant en UTC ; la ligne locale formate la date identique dans la zone du navigateur et nomme cette zone. Les lignes des secondes et des millisecondes conservent les deux formes numériques.

L'horloge locale précise et le décalage doivent être lus à partir de l'appareil exécutant l'exemple ; en publier un ici ferait comme si chaque lecteur avait la même zone. C'est pourquoi cette vérification efficace utilise l'assertion ISO comme résultat fixe et traite la sortie locale comme une valeur observée. Si l'ISO diffère, revisitez l'unité sélectionnée avant d'examiner les paramètres d'emplacement.

Exemple concret : une époque, les trois sorties que ToolAcre expose réellement

Cet itinéraire ne propose pas de sélecteur pour une troisième zone arbitraire. `formatInZone` peut accepter une zone en interne, mais le panneau l'appelle uniquement pour UTC et pour la valeur par défaut du navigateur. Un article affirmant que les utilisateurs peuvent choisir Tokyo, Nairobi ou Toronto décrirait une interface qui n'est pas livrée, même si Intl peut prendre en charge un tel formatage ailleurs.

Il n'expose pas non plus la sélection du calendrier, la sélection des paramètres régionaux ou la révision de la base de données de fuseau horaire. Pour la conversion entre bureaux, conservez l’époque comme point d’ancrage et utilisez un outil dont l’interface documentée nomme la zone cible. Ici, la promesse la plus étroite est précieuse : l'UTC universel à côté de l'environnement local, sans serveur caché décidant de ce que local signifie.

À retenir : votre navigateur est l'horloge et l'atlas - et comment le convertisseur d'horodatage Unix l'utilise pour afficher côte à côte l'UTC et le local sans serveur

Le navigateur agit à la fois comme moteur arithmétique et comme environnement de présentation. ToolAcre résout l'unité, crée une date, demande une valeur ISO canonique, puis formate côte à côte les lectures UTC et locales. Aucun service de conversion à distance n'est nécessaire pour ces étapes, et l'unité affichée conserve la décision du facteur de 1,000 disponible pour examen.

Lorsque les sorties diffèrent d'un appareil à l'autre, comparez la ligne ISO, la note de l'unité et la zone locale nommée dans cet ordre. Ces trois observations séparent instant, échelle et présentation. Traiter l’horloge locale comme la source de vérité regroupe les trois questions en une seule et donne l’impression qu’une conversion correcte est erronée chaque fois que le spectateur change de zone.