Temps

Convertir une heure de chaîne vers/à partir d'une heure numérique

À divers endroits dans ERDDAP, un moment précis peut être représenté comme suit :

Une chaîne - ERDDAP utilise toujours le format "extended" ISO 8601:2004 yyyy-MM-ddTHH:mm:ssZ - par exemple, 2018-01-02T00:00:00Z . Les ensembles de données en dehors d' ERDDAP utilisent souvent un format différent pour les valeurs temporelles des chaînes.
Un nombre - Lors de la représentation des heures sous forme de nombres, ERDDAP écrit toujours un nombre compatible UDUNITS - par exemple, n=473472000 unités= "seconds since 1970-01-01T00:00:00Z" . ERDDAP utilise cette chaîne d'unités exactes pour tous les ensembles de données. Les ensembles de données en dehors d' ERDDAP utilisent souvent des chaînes d'unités différentes.

Cette page Web contient des convertisseurs qui peuvent modifier les valeurs de temps de chaîne (avec différents formats) vers/depuis des valeurs de temps numériques (avec différentes chaînes d'unités). Il dispose également de convertisseurs pour modifier les chaînes de temps et les chaînes d'unités qui utilisent d'autres formats dans les formats utilisés par ERDDAP .

Pour éviter toute confusion entre le fuseau horaire et l'heure d'été, les valeurs horaires dans ERDDAP utilisent toujours le fuseau horaire Zulu (UTC, GMT), désigné par « Z ». Les convertisseurs ci-dessous acceptent les heures de chaîne avec d'autres fuseaux horaires.

Réinitialisez le formulaire aux valeurs par défaut.

Ou contournez cette page Web et effectuez des conversions à partir d’un programme informatique, d’un script ou d’une page Web.

Remarques sur le convertisseur de temps

EXCLUSION DE RESPONSABILITÉ - Aucune personne ou organisation associée à ce site Web n'offre de garantie, expresse ou implicite, y compris les garanties de qualité marchande et d'adéquation à un usage particulier, ou n'assume aucune responsabilité légale quant à l'exactitude, l'exhaustivité ou l'utilité de toute information disponible sur ce site. site web.
IMPARFAIT - Ces convertisseurs sont imparfaits. Vérifiez toujours les résultats de ces convertisseurs.
Ces convertisseurs acceptent un grand nombre de formats temporels de chaînes, mais il y aura toujours des formats qu'ils ne reconnaîtront pas ou n'interpréteront pas différemment que vous. Dans certains cas, il existe deux ou plusieurs manières courantes, mais différentes, d'interpréter un format d'heure donné, notamment #/#/# : aux États-Unis, il s'agit généralement de mois/date/année, alors que dans la plupart des pays d'Europe, cela signifie est généralement destiné à être date/mois/année. Dans ce cas particulier, ERDDAP interprète la valeur comme mois/date/année.
UDUNITS Unités de temps - Par exemple, "seconds since 1970-01-01T00:00:00Z" . Le premier mot peut être (majuscule ou minuscule) :
  ms, msec, msecs, millis, millisecond, milliseconds,
  s, sec, secs, second, seconds,
  m, min, mins, minute, minutes,
  h, hr, hrs, hour, hours,
  d, day, days,
  week, weeks,
  mon, mons, month, months,
  yr, yrs, year, or years .
"since" est requis.
Un autre exemple est "hours since 0001-01-01" .
La chaîne d'heure peut être dans n'importe quel format. La partie date est obligatoire. La partie horaire est facultative. ERDDAP fera de son mieux pour lire le format que vous fournissez. Le format recommandé est le format "extended" ISO 8601:2004 yyyy-MM-dd THH:mm:ss.SSSZ, où Z est « Z » ou un décalage ±hh ou ±hh:mm par rapport au fuseau horaire Zulu /GMT. Si vous omettez Z et le décalage, le fuseau horaire Zulu /GMT est utilisé. Par ailleurs, si vous omettez .SSS, :ss.SSS, :mm:ss.SSS ou Thh:mm:ss.SSS, les champs manquants sont supposés être 0.
Techniquement, ERDDAP ne suit PAS la norme UDUNITS lors de la conversion des valeurs de temps "years since" et "months since" en "seconds since" . La norme UDUNITS définit une année comme une valeur fixe et unique : 3,15569259747e7 secondes. Et UDUNITS définit un mois comme année/12. Malheureusement, la plupart/tous les ensembles de données que nous avons vus et qui utilisent "years since" ou "months since" indiquent clairement que les valeurs sont des années civiles ou des mois civils. Par exemple, 3 "months since 1970-01-01" signifie généralement le 01/04/1970. Ainsi, ERDDAP interprète "years since" et "months since" comme des années civiles et des mois, et ne suit pas strictement la norme UDUNITS .
Précision du convertisseur - Lors de la représentation des heures sous forme de nombres, ce convertisseur laisse toujours les nombres avec leur pleine précision. Lors de la représentation des heures sous forme de chaînes, ce convertisseur formate les heures à la seconde (tronquée) (c'est-à-dire en omettant les millièmes).
Entrée invalide - ERDDAP tente de traiter les entrées mal formatées. Si ERDDAP ne peut pas gérer l'entrée, ERDDAP générera un message d'erreur. Si "l'entrée invalide" est une chaîne time qui, selon vous, devrait être prise en charge, veuillez l'envoyer par e-mail à erd dot data at noaa dot gov .

Comment ERDDAP gère le temps

Le temps est une question difficile, complexe et désordonnée.
Objectif - L'un des objectifs sous-jacents du système ERDDAP de gestion du temps est de disposer d'un système unique permettant de comparer directement les données temporelles de n'importe quel ensemble de données aux données temporelles de n'importe quel autre ensemble de données. Veuillez garder cela à l’esprit lorsque vous lirez les autres commentaires ci-dessous.
Points horaires - ERDDAP ne traite que des points horaires (une date et une heure combinées dans le fuseau horaire Zulu, chacune étant un instant dans le temps).
Fuseaux horaires - Lors de l'écriture des valeurs horaires, ERDDAP utilise toujours le fuseau horaire Zulu (UTC, GMT) et n'utilise jamais l'heure d'été. Les données horaires provenant d'une source contenant des informations sur le fuseau horaire (qui peuvent incorporer des informations sur l'heure d'été) sont converties en heure Zulu . Les données temporelles provenant d'une source sans informations de fuseau horaire sont supposées être déjà à l'heure Zulu .
Précision - ERDDAP traite le temps en interne comme "seconds since 1970-01-01T00:00:00Z", en ignorant les secondes intercalaires, stockées sous forme de nombres à virgule flottante double précision. Ainsi, la plupart des données temporelles peuvent être stockées de manière très précise (à peu près à la microseconde la plus proche, mais progressivement de manière moins précise très loin dans le passé ou le futur).
Lors des calculs, ERDDAP fonctionne souvent à la milliseconde près, pour éviter les problèmes avec les nombres à virgule flottante légèrement supérieurs ou inférieurs à ce que vous attendez.
Lors de la représentation des temps sous forme de nombres, ERDDAP laisse toujours les nombres avec leur pleine précision.
Par défaut, lors de la représentation des heures sous forme de chaînes, ERDDAP formate les heures à la seconde (tronquée) (c'est-à-dire en omettant les millièmes). Cependant, les administrateurs ERDDAP peuvent configurer des variables spécifiques dans des ensembles de données spécifiques pour représenter les heures de chaîne avec d'autres précisions (par exemple, de la précision en millisecondes jusqu'à la précision en mois ; voir l'attribut de variable <time_precision> ). Chaque fois qu'un champ temporel (par exemple, millisecondes ou secondes) n'est pas affiché, la valeur absente est supposée être 0 (sauf pour le jour du mois, qui est supposé être 1).
Unités cohérentes - L'utilisation des mêmes unités de temps ("seconds since 1970-01-01T00:00:00Z" ) pour tous les ensembles de données permet de comparer facilement les temps de différents ensembles de données. Les secondes sont le Système International d'Unités (SI) unité de base de temps. 1970-01-01T00:00:00Z marque le début de l’ère Unix, largement utilisée par les systèmes d’exploitation informatiques. "seconds since 1970-01-01T00:00:00Z" sont largement utilisées et sont souvent appelées heure Unix. ou secondes d'époque. L'utilisation de la chaîne d'unités "seconds since 1970-01-01T00:00:00Z" rend l'heure Unix compatible avec UDUNITS et les Conventions sur les métadonnées sur le climat et les prévisions (CF) , qui utilise UDUNITS pour les définitions d'unités.
Représentation textuelle - Par défaut, lors du formatage des heures sous forme de texte, ERDDAP utilise la chaîne de format "extended" ISO 8601:2004. , tronqué à la seconde (par exemple, 2011-04-26T14:07:12Z). (Humour connexe : https://xkcd.com/1179/ ) Les administrateurs ERDDAP peuvent configurer une variable donnée pour afficher les valeurs des données temporelles avec une plus grande précision (tronquée à 0,001 seconde, 0,01 seconde, 0,1 seconde) ou avec une précision moindre (tronquée à la seconde, la minute, l'heure, la date ou le mois) pour indiquer le précision des valeurs des données temporelles.
Lors de la lecture des temps ISO 8601 avec des secondes décimales, ERDDAP accepte un séparateur de points (par exemple, 2011-04-26T14:07:12,059Z) ou une virgule (par exemple, 2011-04-26T14:07:12,059Z). Actuellement, lors de l'écriture de la norme ISO 8601, ERDDAP utilise toujours un séparateur de points.
Calendrier grégorien - ERDDAP utilise le calendrier grégorien pour les temps postérieurs à la discontinuité de 1582 et le calendrier julien pour les temps antérieurs à la discontinuité. (La norme ISO 8601:2004 ne précise pas comment gérer les heures avant 1582.) Voir la classe Java GregorianCalendar. (ERDDAP utilise) pour plus de détails. Par exemple, 17611992 heures depuis 0001-01-01T00:00:00Z = 2010-03-01T00:00:00Z (voyez par vous-même)
Actuellement, ERDDAP ne prend en charge aucun autre calendrier (y compris les calendriers noleap, 365_day, 360_day et Julian définis par les conventions de métadonnées CF ). Cependant, vous pouvez stocker ces données dans ERDDAP en stockant les nombres ou les chaînes dans une variable nommée autre chose que "time" et n'incluant pas "since" dans les métadonnées des unités. Ensuite, ERDDAP n'interprétera pas les valeurs comme des heures et ne convertira pas les données en "seconds since 1970-01-01T00:00:00Z" . Les utilisateurs pourront accéder aux données dans leur forme originale.
Indulgent – ERDDAP est « indulgent » lorsqu’il analyse les chaînes de date/heure. Cela signifie que la date/l'heure au format correct, mais avec des valeurs de mois, de date, d'heure, de minute et/ou de seconde trop grandes ou trop petites, seront converties en date/heures appropriées. Par exemple, ERDDAP interprète le 2001-12-32 comme le 2002-01-01 et le 2002-01-00 comme le 2001-12-31. (Ce n'est pas un bug, c'est une fonctionnalité ! Nous comprenons que vous puissiez vous y opposer si vous n'êtes pas familier avec l'analyse clémente. Nous comprenons qu'il y a des circonstances où certaines personnes préféreraient une analyse stricte, mais il y a aussi des circonstances où certaines personnes préféreraient L'analyse indulgente. ERDDAP ne peut pas jouer sur les deux tableaux. C'était un choix conscient. L'analyse indulgente est le comportement par défaut de Java, le langage dans lequel ERDDAP est écrit et sans doute le langage informatique le plus utilisé. ERDDAP convertit les valeurs d'axe de grille demandées en valeur d'axe de grille valide la plus proche et cela est cohérent avec d'autres endroits dans ERDDAP qui tentent de réparer les entrées invalides lorsque l'intention est claire, au lieu de simplement renvoyer un message d'erreur.)
Années BCE (BC) et numérotation des années astronomiques - Comme spécifié dans la norme ISO 8601:2004, ERDDAP utilise uniquement l'ère commune (CE, AD) pour les numéros d'année, et non BCE. Pour les années précédant 1 CE, les historiens utilisent la désignation BCE ou BC et pas d'année 0, donc leur séquence d'années proches de la transition d'ère est 2 BCE, 1 BCE, 1 CE, 2 CE. Pendant des années avant 1 avant notre ère, la norme ISO 8601:2004 (d'après ma lecture) encourage l'utilisation d'un système différent : la numérotation des années astronomiques. , dans laquelle 1 BC est appelé année 0000, 2 BC est appelé année -0001, etc. Puisque la numérotation des années astronomiques est encouragée par la norme ISO 8601:2004 et utilisée par de nombreux domaines scientifiques, et parce que les océanographes et les climatologues utilisent souvent l'année 0000 pour les climatologies, ERDDAP utilise la numérotation des années astronomiques. Ainsi, les années proches de la transition d’ère dans ERDDAP sont respectivement -0001, 0000, 0001 et 0002. Ainsi, pour les années BCE : AstronomicalYear = 1 - BCEYear (voyez par vous-même : test1, test2 et test3). Un avantage de la numérotation des années astronomiques est que toutes les années bissextiles sont divisibles par 4, par exemple, ..., -0008, -0004, 0000, 0004, 0008, .... Si vous pensez à utiliser les numéros des années astronomiques, ERDDAP fonctionnera. pour des dates lointaines dans le passé et dans le futur.
Le SeaDataNet le projet stocke l'heure sous la forme "jours depuis -4713-01-01T00:00:00Z", qui fait référence à minuit au début du 1er janvier 4713 avant notre ère, qui est l'heure de début des Chronological Julian Dates (CJD) . Ainsi, dans la configuration datasets.xml pour un ensemble de données SeaDataNet dans ERDDAP, dans la section <addAttributes> pour toutes les variables temporelles, vous devez ajouter
<att name="units">days since -4712-01-01T00:00:00Z</att>
de sorte que 4713 avant notre ère est exprimé comme le numéro de l'année astronomique -4712. À titre de contrôle, notez que le début du jour chronologique julien numéro 2 452 952 (ou 2452952 "days since -4712-01-01") est le 2003-11-08T00:00:00Z.
UTC - Dans la mesure du possible, ERDDAP, comme l'heure Unix et UDUNITS, utilise le temps universel coordonné (UTC) système de temps. UTC est la version moderne du système horaire GMT. UTC utilise occasionnellement des secondes intercalaires pour rester proche du temps atomique international (TAI). Les appareils GPS utilisent l'heure GPS (qui n'utilise pas de secondes intercalaires) en interne, mais affichent l'heure UTC aux utilisateurs. (Voir https://www.cnmoc.usff.navy.mil/Our-Commands/United-States-Naval-Observatory/Precise-Time-Department/The-USNO-Master-Clock/Definitions-of-Systems-of- Temps/ ou d'autres discussions sur les systèmes de temps.) À proprement parler, UTC ne peut pas être utilisé dans certaines situations pour des temps lointains (par exemple, dans les modèles), car l'apparition de secondes intercalaires ne peut pas être prédite.
Secondes intercalaires - Comme l'heure Unix et UDUNITS, "seconds since 1970-01-01T00:00:00Z" d' ERDDAP sont un codage numérique (qui n'utilise pas de secondes intercalaires) de l'heure UTC (qui utilise des secondes intercalaires). Lors de la conversion des heures de chaîne vers/depuis des heures numériques, ERDDAP, comme l'heure Unix et UDUNITS, ignore les secondes intercalaires. Pourtant, ERDDAP, l'heure Unix et l'heure numérique UDUNITS indiquent toutes qu'elles utilisent UTC. Voici pourquoi et comment : étant donné que les horloges informatiques ne sont pas de bons chronométreurs, elles s'éloignent de l'heure UTC et doivent être réinitialisées à l'heure UTC de temps en temps. L'heure Unix traite les secondes intercalaires comme faisant partie de l'écart temporel provoqué par la dérive de l'horloge. Cela permet au logiciel d'effectuer un codage temporel et des calculs temporels et d'ignorer les secondes intercalaires. Avec les valeurs de temps numériques ERDDAP, Unix et UDUNITS, toutes les minutes sont traitées comme ayant 60 secondes, même si les minutes UTC avec secondes intercalaires ont 61 secondes. Notez que les programmes de base de données comme Oracle , MySQL (et donc probablement MariaDB aussi), PostgreSQL , et des langages comme C# essayez également d'ignorer les secondes intercalaires. Cela ne posera pas de problèmes lors de la conversion des valeurs de chaîne UTC date+heure+timeZone en valeurs numériques ERDDAP si les heures sont ensuite reconverties en date+heure+ chaînes Zulu d'une manière qui ignore également les secondes intercalaires. Les deux erreurs s’annuleront. Une conséquence malheureuse est que les heures numériques ERDDAP, Unix et UDUNITS n'ont aucun mécanisme pour coder sans ambiguïté les secondes intercalaires réelles sous forme de nombres. Par exemple, la seconde intercalaire 2008-12-31T23:59:60Z et la seconde suivante 2009-01-01T00:00:00Z sont codées en 1230768000 seconds since 1970-01-01T00:00:00Z . Il s'agit d'un défaut, mais qui n'affecte que les secondes intercalaires réelles. De même, si vous devez calculer le nombre exact de secondes UTC entre deux moments, vous pouvez utiliser ERDDAP pour gérer les données temporelles, mais soustraire une valeur temporelle numérique de l'autre n'est que la première étape du calcul. Vous devez ajuster manuellement cette valeur en consultant un tableau de secondes intercalaires .
Durées et intervalles de temps à basse résolution (plages de temps) - Si les données temporelles ont été enregistrées avec une résolution inférieure (par exemple, une minute, une heure, un jour, un mois ou une année) ou représentent une période de temps (par exemple, une heure, un jour, 7 -jour, mois, année), ERDDAP exige qu'un point temporel (nous l'appelons « heure nominale ») soit utilisé pour représenter cette heure ou cette période. L’utilisation d’une heure nominale permet aux points temporels, aux points temporels à faible résolution et aux intervalles de temps d’être interopérables. (Imaginez visualiser différents ensembles de données dans un programme comme Google Earth et utiliser un curseur temporel pour contrôler quel sous-ensemble de données est visible.) Les points temporels les plus couramment sélectionnés pour l'heure nominale sont l'heure de début et l'heure centrée (moins courante, mais a avantages pour une utilisation avec des curseurs temporels). Nous vous recommandons d'utiliser les métadonnées long_name pour identifier cela (par exemple, « Heure de début » ou « Heure centrée »). Pour les temps de faible résolution, considérez par exemple « Date », « Mois » et « Année ». Et/ou, mettez les détails dans les métadonnées "comment" de la variable.
Ou, pour représenter plus précisément les périodes de temps, vous pouvez configurer un ensemble de données pour avoir à la fois une variable beginTime et une variable endTime (et même une centeredTime, si vous souhaitez couvrir toutes les possibilités).
Ce sont des réponses imparfaites. La configuration actuelle tente de mettre de l'ordre dans le chaos du format temporel, gère raisonnablement bien la plupart des situations et correspond aux attentes de la plupart des gens concernant le fonctionnement du temps (même s'ils n'y ont pas réfléchi en détail), mais pas toutes. Mais c’est ainsi que fonctionne actuellement ERDDAP .

Vous souhaitez effectuer des conversions de temps à partir d'un programme informatique, d'un script ou d'une page Web ?

Si vous modifiez l'extension de l'URL de cette page Web de .html à .txt, ERDDAP répondra avec uniquement le résultat textuel.

Un exemple qui convertit une heure de chaîne en heure numérique est :
https://cioosatlantic.ca/erddap/fr/convert/time.txt?stringTime=1985-01-02T00:00:00Z&units=seconds%20since%201970-01-01T00:00:00Z
Vous pouvez également utiliser un autre format, par exemple :
https://cioosatlantic.ca/erddap/fr/convert/time.txt?stringTime=Jan%202,%201985&units=seconds%20since%20Jan%201,%201970
Un exemple qui convertit une heure numérique en une heure de chaîne est :
https://cioosatlantic.ca/erddap/fr/convert/time.txt?n=473472000&units=seconds%20since%201970-01-01T00:00:00Z
Le format recommandé pour l'heure de base dans les unités est le format ISO 8601, mais vous pouvez spécifier l'heure de base dans n'importe quel format courant, par exemple :
https://cioosatlantic.ca/erddap/fr/convert/time.txt?n=473472000&units=seconds%20since%201/1/1970
Notez que le format "slash" est interprété à la manière américaine (comme mois/date/année) et non à la manière européenne (comme date/mois/année).
Dans certaines versions précédentes d' ERDDAP, le convertisseur de chaîne en numérique nécessitait une chaîne au format ISO 8601 et utilisait le nom de paramètre isoTime. Vous pouvez toujours l'utiliser, par exemple,
https://cioosatlantic.ca/erddap/fr/convert/time.txt?isoTime=1985-01-02T00:00:00Z&units=seconds%20since%201970-01-01T00:00:00Z
Si vous spécifiez isoTime, le paramètre "&units=..." est facultatif. La valeur par défaut est "seconds since 1970-01-01T00:00:00Z" .
Un exemple qui convertit n'importe quelle heure de chaîne courante en heure de chaîne ISO 8601 est :
https://cioosatlantic.ca/erddap/fr/convert/time.txt?stringTime=1/2/1985
Vous devez spécifier une partie date. La partie horaire est facultative. Si vous spécifiez simplement une date, le convertisseur renverra la valeur qui sera simplement une date. Si vous spécifiez une partie date et une partie heure, le convertisseur renverra une date et une heure.
Notez que le format "slash" est interprété à la manière américaine (comme mois/date/année) et non à la manière européenne (comme date/mois/année).
Un exemple qui convertit une chaîne d'unités en chaîne d'unités avec une chaîne ISO de temps est :
https://cioosatlantic.ca/erddap/fr/convert/time.txt?units=SEC%20SINCE%20Jan%202%2C%201985

Encodage en pourcentage : les valeurs des paramètres dans l'URL (les parties après les signes '=' ) doivent être correctement codées en pourcentage. (external link) : tous les caractères autres que A-Za-z0-9_-!.~'()* doivent être codés en %HH, où HH est la valeur hexadécimale à 2 chiffres du caractère, par exemple, un espace devient %20. Les caractères au-dessus de #127 doivent être convertis en octets UTF-8, puis chaque octet UTF-8 doit être codé en pourcentage (demandez de l'aide à un programmeur). Il existe des sites Web qui encodent et décodent pour vous (external link) .