Interprétation de la date et de l’heure

Les dates et heures publiées dans Darwin Core devraient utiliser la norme ISO 8601-1:2019. Un seul jour est représenté au format année-mois-jour (YYYY-MM-DD), par exemple 2023-09-18. Une heure peut être ajoutée en ajoutant T et l’heure au format 24 heures, par exemple 2023-09-18T13:27:00.

Les fuseaux horaires peuvent être fournis 2023-09-18T13:27:00Z (UTC, GMT) et 2023-09-18T15:27:00+02:00 (heure d’été d’Europe centrale) représentent tous deux le même moment dans le temps, mais voir ci-dessous pour savoir comment nous traitons les informations relatives aux fuseaux horaires.

Lorsque la date n’est pas précise, et que seuls le mois ou l’année sont connus, le jour ou le mois peuvent être omis. 2023-09 signifie une date quelconque en septembre 2023, 2023 signifie une date quelconque en 2023.

Un intervalle de temps peut être représenté en séparant deux date-heures avec une précision égale à l’aide de /, par exemple 2023-09-05/2023-09-18 signifie une date comprise entre le 5 septembre 2023 et le 18 septembre 2023. 2023-01/2023-09 signifie janvier à septembre 2023, 2000/2023 couvre une période de 24 ans du début de l’année 2000 à la fin de l’année 2023, et 2023-09-10T03:54:00/2023-09-18T13:27:30 est une plage dont le début et la fin sont précis à la seconde près.

La norme ISO 8601-1:2019 inclut une forme abrégée pour les intervalles de date, dans laquelle les parties de la date qui ne sont pas changées peuvent être omises. Pour faciliter l’analyse pour les utilisateurs de l’API, nous normalisons cela sous la forme complète : 2023-09-05/18 devient 2023-09-05/2023-09-18, 2023-01/09 devient 2023-01/2023-09 etc.

Le système GBIF supporte seulement les date-heures qui représentent des intervalles dans certains champs ; voir ci-dessous.

Les dates fournies dans d’autres formats (March 1986, 13.03.1986, 03/13/1986, 13.III.1986, 13 March 1986 to 5 April 1987 etc.) peuvent être interprétées, lorsque cela est possible sans ambiguïté, mais ces formats ne sont pas recommandés. Les occurrences dont les dates ne peuvent être traitées seront signalées par les problèmes DATE_D’ENREGISTREMENT_NON_VALIDE, DATE_D’IDENTIFICATION_ NON_VALIDE, DATE_GÉORÉFÉRENCÉE_NON_VALIDE ou DATE_DE_MODIFICATION_NON_VALIDE. Darwin Core inclut un champ de verbatimEventDate pour enregistrer la date originale.

En plus, les occurrences seront signalées par les problèmes DATE_D’ENREGISTREMENT_PEU_PROBABLE, DATE_D’IDENTIFICATION_PEU_PROBABLE, DATE_GÉORÉFÉRENCÉE_PEU_PROBABLE or DATE_DE_MODIFICATION_PEU_PROBABLE si ces dates sont dans le futur ou si loin dans le passé qu’elles sont peu probables.

Huit champs Darwin Core représentent tout ou partie de la date et de l’heure auxquelles une occurrence a été enregistré :

ÀFAIRE : Décrire comment cella affecte les enregistrements publiés à l’aide de BioCASe.

Avec six champs, il existe la possibilité de conflit entre les valeurs. Nos procédures d’interprétation tentent de trouver une date cohérente avec les valeurs fournies, en ajoutant des problèmes à l’enregistrement d’occurrence s’il y a des problèmes. Si des valeurs sont manquantes mais ne sont pas en conflit, elles sont ajoutées sans qu’un problème soit signalé.

Voici des exemples d’enregistrements après interprétation, où les six champs sont cohérents :

Notez que les informations relatives au fuseau horaire ne sont conservées que lorsque le fuseau horaire est Z (UTC). Dans d’autres cas, les informations relatives au fuseau horaire varient considérablement d’une donnée à l’autre, et il n’est pas possible de les traiter de manière cohérente. Un enregistrement fourni avec eventDate 2023-01-13T09:32:00+01:00 (Copenhague, Danemark) et un autre fourni avec 2023-01-13T09:32:00+14:00 (Îles de la Ligne, Kiribati) seront interprétés comme 2023-01-13T09:32:00.

La publication d’une combinaison de eventDate et/ou year+month+day et/ou year+startDayOfYear+endDayOfYear permet au GBIF de calculer un ensemble cohérent de champs de date enregistrés. Si vous fixez plusieurs de ces ensembles de champs, assurez-vous qu’ils sont cohérents !

Le champ identifiedDate est interprété comme une date unique ou une date-heure (et non comme un intervalle).

Le champ georeferencedDate est interprété comme une date unique ou une date-heure (et non comme un intervalle).

Le champ modified est interprété comme une date unique ou une date-heure (et non comme un intervalle).

Les occurrences sont renvoyées par les API de recherche et de téléchargement si la date/plage de dates d’occurrence se situe entièrement dans la date ou la plage de dates de la requête.

Cette implémentation évite de renvoyer des occurrences avec des eventDates telles que "2000/2021" dans de nombreuses requêtes. (Il existe des millions d’occurrences avec des plages aussi larges.)