Temps

Convertir une date+heure en "string" en/depuis une date+heure numérique

À divers endroits dans ERDDAP, un point dans le temps peut être représenté soit :

Une chaîne - ERDDAP utilise toujours le format ISO 8601:2004 "extended" 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 units= "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 temporelles des chaînes (avec différents formats) vers/depuis les valeurs temporelles numériques (avec différentes chaînes d'unités). Il dispose également de convertisseurs pour changer 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

AVIS DE NON-RESPONSABILITÉ - Aucune personne ou organisation associée à ce site Web ne donne 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 pour l'exactitude, l'exhaustivité ou l'utilité de toute information contenue dans ce site. site Internet.
IMPARFAIT - Ces convertisseurs sont imparfaits. Vérifiez toujours les résultats de ces convertisseurs.
Ces convertisseurs acceptent un grand nombre de formats d'heure de chaîne, mais il y aura toujours des formats qu'ils ne reconnaîtront pas ou n'interpréteront pas différemment de vous. Dans certains cas, il existe au moins deux manières courantes, mais différentes, d'interpréter un format d'heure donné, notamment #/#/# : aux États-Unis, il s'agit généralement du mois/date/année, alors que dans la plupart est généralement destiné à être date/mois/année. Dans ce cas particulier, ERDDAP interprète la valeur comme mois/date/année.
Unités de temps UDUNITS - 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.
Donc, 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 temps est facultative. ERDDAP fera de son mieux pour lire le format que vous fournissez. Le format recommandé est le format ISO 8601:2004 "extended" yyyy-MM-dd THH:mm:ss.SSSZ, où Z est 'Z' ou un décalage de ±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é. Séparément, 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 unique fixe : 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 qui utilisent "years since" ou "months since" prévoient 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 1970-04-01. 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 à 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 millisecondes).
Entrée non valide - ERDDAP essaie de traiter une entrée mal formatée. Si ERDDAP ne peut pas traiter l'entrée, ERDDAP générera un message d'erreur. Si l'"entrée non valide" est une heure de chaîne qui, selon vous, devrait être prise en charge, veuillez l'envoyer par e-mail à erd dot data at noaa dot gov .

Comment ERDDAP le temps

Le temps est une question difficile, complexe et désordonnée.
Objectif - Un objectif sous-jacent du système ERDDAP pour gérer le temps est d'avoir un système unique qui permet aux données temporelles de n'importe quel ensemble de données d'être comparées directement aux données temporelles de tout autre ensemble de données. Veuillez garder cela à l'esprit lorsque vous lisez les autres commentaires ci-dessous.
Points de temps - ERDDAP ne traite que des points de temps (une date+heure combinée dans le fuseau horaire Zulu, chacun é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 d'heure d'une source avec des informations de fuseau horaire (qui peuvent inclure des informations sur l'heure d'été) sont converties en heure Zulu . Les données temporelles d'une source sans informations de fuseau horaire sont supposées être déjà en heure Zulu .
Précision - ERDDAP traite le temps en interne en tant que "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 près, mais de moins en moins précisément très loin dans le passé ou le futur).
Lors des calculs, ERDDAP travaille souvent à la milliseconde près, pour éviter les problèmes avec les nombres à virgule flottante qui sont légèrement plus ou moins que prévu.
Lors de la représentation des temps sous forme de nombres, ERDDAP laisse toujours les nombres à 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 millisecondes). 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 à d'autres précisions (par exemple, de la précision de la milliseconde à la précision du mois ; voir l'attribut de variable <time_precision> ). Chaque fois qu'un champ de temps (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 heures de différents ensembles de données. Les secondes sont le système international d'unités (SI) unité de temps de base. 1970-01-01T00:00:00Z est le début de l'ère Unix, qui est 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 temps 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 de texte - 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 à une précision moindre (tronquée à la seconde, à la minute, à l'heure, à la date ou au mois) pour indiquer le précision des valeurs des données temporelles.
Lors de la lecture ISO 8601 fois avec des secondes décimales, ERDDAP accepte un séparateur de période (par exemple, 2011-04-26T14:07:12.059Z) ou un séparateur de virgule (par exemple, 2011-04-26T14:07:12,059Z). Actuellement, lors de l'écriture ISO 8601 fois ERDDAP utilise toujours un séparateur de période.
Calendrier grégorien - ERDDAP utilise le calendrier grégorien pour les temps après la discontinuité en 1582 et le calendrier julien pour les temps avant la discontinuité. (La norme ISO 8601:2004 ne spécifie pas comment gérer les temps avant 1582.) Voir la classe Java GregorianCalendar (ERDDAP ) 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 de telles données dans ERDDAP en stockant les nombres ou les chaînes dans une variable nommée autrement que "time" et n'incluant pas "since" dans les métadonnées des unités. Ensuite, ERDDAP 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.
ERDDAP est "clément" lorsqu'il analyse les chaînes de date/heure. Cela signifie que les dates/heures avec le format correct, mais avec des valeurs de mois, date, heure, minute et/ou seconde trop grandes ou trop petites seront reportées à la date/heures appropriées. Par exemple, ERDDAP interprète le 2001-12-32 comme 2002-01-01 et interprète le 2002-01-00 comme 2001-12-31. (Ce n'est pas un bogue, c'est une fonctionnalité ! Nous comprenons que vous pouvez vous y opposer si vous n'êtes pas familier avec l'analyse syntaxique 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 analyse syntaxique clémente. ERDDAP ne peut pas jouer sur les deux tableaux. C'était un choix conscient. L'analyse syntaxique clémente est le comportement par défaut de Java, le langage dans lequel ERDDAP est écrit et sans doute le langage informatique le plus utilisé. De plus, ce comportement est cohérent avec Conversion par ERDDAP des 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 essaient de réparer les entrées non valides 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 simplement l'ère commune (CE, AD) pour les numéros d'année, pas BCE. Pour les années avant 1 CE, les historiens utilisent la désignation BCE ou BC et pas d'année 0, donc leur séquence d'années près de la transition d'ère est 2 BCE, 1 BCE, 1 CE, 2 CE. Pendant des années avant 1 BCE, la norme ISO 8601:2004 (selon 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. Étant donné que la numérotation des années astronomiques est encouragée par 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 astronomique des années. Ainsi, les années proches de la transition d'ère dans ERDDAP sont -0001, 0000, 0001, 0002, respectivement. 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 vous souvenez d'utiliser les numéros des années astronomiques, ERDDAP fonctionnera pour des dates lointaines dans le passé et le futur.
Le SeaDataNet le projet stocke l'heure sous la forme "jours depuis -4713-01-01T00:00:00Z", qui est une référence à minuit au début du 1er janvier 4713 BCE, 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 AEC est exprimé comme le nombre d'année astronomique -4712. À titre de vérification, notez que le début du jour chronologique julien numéro 2 452 952 (ou 2452952 "days since -4712-01-01") est 2003-11-08T00:00:00Z.
UTC - Autant que 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 d'heure GMT. UTC utilise des secondes intercalaires occasionnelles pour rester proche de l'heure atomique internationale (TAI). Les appareils GPS utilisent l'heure GPS (qui n'utilise pas les 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-Time/ 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 des modèles), car l'occurrence de secondes intercalaires ne peut pas être prédite.
Secondes ERDDAP - Comme l'heure Unix et UDUNITS, les "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 d'heures de chaîne en/à partir d'heures numériques, ERDDAP, comme l'heure Unix et UDUNITS, ignore les secondes intercalaires. Pourtant, les heures numériques ERDDAP, Unix et UDUNITS indiquent toutes qu'elles utilisent l'UTC. Voici pourquoi et comment : Étant donné que les horloges d'ordinateur ne sont pas de bons chronométreurs, elles dérivent de l'heure UTC et doivent être réinitialisées à l'heure UTC de temps en temps. Le temps Unix traite les secondes intercalaires comme faisant partie de l'écart de temps causé par la dérive de l'horloge. Cela permet au logiciel d'encoder et de calculer le temps 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 date+heure+heureZone de la chaîne UTC en valeurs numériques ERDDAP si les heures sont ensuite reconverties en chaînes date+heure+ Zulu d'une manière qui ignore également les secondes intercalaires. Les deux erreurs s'annuleront. Une conséquence malheureuse est que les temps numériques ERDDAP, Unix et UDUNITS n'ont aucun mécanisme pour coder les secondes intercalaires réelles sous forme de nombres sans ambiguïté. 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 . C'est un défaut, mais cela n'affecte que les secondes intercalaires réelles. De même, si vous devez calculer le nombre exact de secondes UTC entre deux points dans le temps, vous pouvez utiliser ERDDAP pour gérer les données temporelles, mais soustraire une valeur de temps numérique de l'autre n'est que la première étape du calcul. Vous devez ajuster manuellement cette valeur en consultant un tableau des secondes intercalaires .
Heures et plages de temps à faible résolution (plages de temps) - Si les données temporelles ont été enregistrées à une résolution inférieure (par exemple, une minute, une heure, un jour, un mois ou une année) ou représentent une plage de temps (par exemple, une heure, un jour, 7 -jour, mois, année), ERDDAP exige qu'un point de temps (nous l'appelons le "temps nominal") soit utilisé pour représenter ce temps ou cette période. L'utilisation d'un temps nominal 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 avantages à utiliser avec les curseurs temporels). Nous vous recommandons d'utiliser les métadonnées long_name pour l'identifier (par exemple, "Heure de début" ou "Heure centrée"). Pour les heures à 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 intervalles de temps, vous pouvez configurer un ensemble de données pour avoir à la fois une beginTime et une variable endTime (et même un 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 sur le fonctionnement du temps (même s'ils n'y ont pas réfléchi en détail), mais pas tous. Mais c'est ainsi que fonctionne l' ERDDAP actuellement.

Vous voulez effectuer des conversions temporelles à 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 une 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
Ou, vous pouvez 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 des États-Unis (comme mois/date/année) et non comme à la manière européenne (comme date/mois/année).
Dans certaines versions précédentes d' ERDDAP, le convertisseur 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 commune en une 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 temps est facultative. Si vous spécifiez simplement une date, le convertisseur renverra une valeur qui ne sera qu'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 des États-Unis (comme mois/date/année) et non comme à la manière européenne (comme date/mois/année).
Un exemple qui convertit une chaîne d'unités en une chaîne d'unités avec un temps de chaîne ISO 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 encodé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 en pourcentage pour vous (external link) .