Vous pouvez choisir de fermer certains des volets de commande et d'information selon votre besoin.

Les boutons Ok en bleu foncé mettent à jour tous les champs en fonction des champs voisins modifiés.

Choisissez le calendrier avec lequel vous spécifiez une date en année, numéro de mois, jour. La validité de la date saisie n'est pas contrôlée: si vous saisissez 31 pour un mois de 30 jours, la date est transformée en 1er du mois suivant.

Vous pouvez spécifier votre date en référence de semaines.

Si vous choisissez le calendrier historique, vous pouvez modifier la date de passage au grégorien.

L'année peut être saisi sans limite haute ni basse, toutefois le navigateur renvoie une alerte si le calcul de date échoue, notamment parce que l'année est hors du domaine de validité. Selon la norme JavaScript, les dates les plus éloignées sont

• pendant l'année -271821 pour la plus ancienne,
• pendant l'année 275760 pour la plus éloignée dans le futur.

On peut fixer la date à Maintenant, l'instant actuel. On peut reculer ou avancer par pas d'un nombre décimal de jours.

Sous la ligne de l'heure, on peut reculer ou avancer par pas d'un nombre entier de millisecondes. Il n'y a pas de limite haute à ce nombre.

Le mode concerne la gestion du fuseau horaire système, défini à partir des paramètres du terminal ou du navigateur.

• Fuseau système: l'heure locale est celle du fuseau horaire paramétré sur votre terminal. Il est tenu compte des éventuelles règles d'heure d'été et d'hiver. Les meilleurs navigateurs gèrent l'historique des heures locales dans les villes de référence. Dans ce mode, le champ Décalage indique le nombre effectif de minutes et secondes qu'il faut ajouter à l'heure UTC pour obtenir l'heure du fuseau horaire système. C'est le décalage horaire selon la définition officielle. Ce décalage est calculé en comparant l'heure locale système à l'heure UTC.

• UTC: l'heure du Temps Universel Coordonné, l'heure du jour moyen au méridien de Greenwich. Dans ce mode, la date et l'heure saisies sont réputées celles du fuseau horaire Z, celui du méridien de Greenwich.

L'écart, différence algébrique entre l'heure UTC et l'heure locale, est donné de deux manières. L'écart réel est obtenu en comparant l'heure locale à l'heure UTC rendue par les primitives Javascript. L'écart système est celui donné par une primitive spécifique. Les navigateurs ne se comportent pas tous de la même manière. Avec le projet Temporal, il n'y aura plus d'ambigüité.

Les boutons 0 h et 12 h fixent l'heure respectivement à 0 h ou 12 h UTC pour la même date UTC. Attention, il peut donc y avoir un saut de la date indiquée en heure locale.

Quand les champs de texte sont vides, la valeur par défaut du système est utilisée.

Vous pouvez spécifier:

• Le code langue-pays, souvent appelé "Locale". Le français parlé en France est codé "fr-FR". Observer les différences entre "en-US" et "en-GB".
• Le calendrier Unicode, à choisir dans la liste.

• Les extensions Unicode, dont le système de numération. Pour un calendrier il faut indiquer "ca-code_calendrier",  pour un système de numération: "nu-code". Vous pouvez spécifier un code calendrier abandonné, comme "islamicc", certains navigateurs le remplacent correctement. Vous pouvez spécifier par exemple nu-arab pour voir les chiffres indiens qu'utilisent certains pays arabes. Le système de numération latn utilisent les chiffres arabes, ceux que nous utilisons tous les jours. Les chiffres romains sont prévus par nu-roman.

Contrairement aux autres outils de ce site, toutes les options de présentation de la date sont mises à disposition. Ce sont les options que le concepteur de site web peut indiquer en vue de faire écrire une date selon un calendrier et une langue. Ces fonctions sont élaborées par le navigateur et éventuellement modifiées: la ligne "Effectif" du tableau indique la mention retenue par le navigateur pour l'affichage.

La mention "Affichage de l'ère" est une option expérimentale en vue d'améliorer l'affichage de dates dans des calendriers avec ère. Quand l'ère de la date à afficher est la même que celle de la date système courante, celle-ci n'est pas affichée même si les paramètres de présentation spécifient l'affichage de l'ère. Par exemple, en calendrier julien on n'affiche l'ère que si celle-ci est "av. J.-C."; en calendrier japonais, on n'affiche pas l'ère actuelle (Reiwa), mais on affiche l'ère de toute date antérieure au 1er mai 2019, début de la nouvelle ère. Ce fonctionnement est par défaut, mais le champ d'option "Affichage de l'ère" permet d'en garder le contrôle, en forçant l'affichage de l'ère dans tous les cas ou au contraire en l'interdisant. Les résultats peuvent être comparés à l'affichage standard.

Les affichages de la date saisie au premier volet sont calculés selon les options d'affichage, avec l'outil d'internationalisation et les données internationales (CLDR) pris en charge par le navigateur.

Vous pouvez comparer la présentation standard du calendrier Unicode de la présentation calculée par nos outils. Observez notamment comment nous restituons les heures et minutes, ainsi que les date antérieures à l'an 1.

Avec les calendriers utilisateurs, vous pouvez obtenir d'autres informations, comme les données de semaine (voir le premier volet) et le type d'année. Ce sera le cas avec Temporal, pour tous les calendriers (Unicode et utilisateurs).

Avec l'option supplémentaire que nous proposons, et avec le calendrier "grégorien" que nous avons conçu, les dates en calendrier julien, avant le passage au grégorien, apparaissent avec l'indication "av. Jésus-Christ" ou "calendrier julien". Dans d'autres langues, on indique un équivalent à "style ancien" pour les dates après J.-C. mais avant la date où la réforme grégorienne a pris effet. Les dates postérieures au passage en grégorien, celle du régime actuel, sont affichées sans indication ou, si l'on positionne l'option "affichage de l'ère", avec l'indication "calendrier grégorien" ou "style nouveau" selon la langue..

Les calendriers non Unicode affichés par le testeur mettent en jeu les principes et certains des outils Unicode. Ils sont développés sous forme de maquettes, en vue d'une possible insertion parmi les calendriers Unicode.

A l'aide du testeur, nous avons pu mettre en valeur:

• l'utilisation des données Unicode pour ordonner et séparer les éléments de dates selon les usages spécifiques à chaque langue (ex. virgule en langue en-US, point après le quantième en allemand...),
• le remploi des noms de mois du calendrier grégorien pour afficher en calendrier julien,
  
• l'assimilation du format de mois numérique à la notation 1m, 2m etc. pour les mois milésiens,
• l'utilisation des monogrammes de mois milésiens (correspondant à l'affichage "étroit" des mois),
  
• l'affichage de mois écrits de gauche à droite dans des langues écrites de droite à gauche, comme l'arabe et l'hébreu,
• la possibilité de conditionner l'affichage de l'ère au fait que l'ère à afficher soit différente de l'ère courante.

Le calendrier Unicode associé aux langues des pays d'Europe et d'Amérique a pour code 'gregory'. L'on croit que c'est le calendrier grégorien classique, c'est-à-dire le calendrier promulgué par Jules César en 45 av. J.-C., enrichi par le monde chrétien avec les semaines, l'année de référence et le calcul de Pâques, et finalement réformé par le pape Grégoire XIII en 1582 pour corriger le décalage accumulé par rapport à l'année solaire. Mais c'est en réalité un calendrier grégorien proleptique. Les dates antérieures à 1582 sont calculées selon les règles grégoriennes, et ne correspondent donc pas aux dates connues en histoire. Unicode propose un autre calendrier, de code 'iso8601', qui est réputé représenté le calendrier normalisé par l'ISO sous la référence 8601. Cette norme dispose que les dates sont toujours présentées sous le format AAAA-MM-JJ, et calculées selon les règles du calendrier grégorien. De plus les années sont notées de manière algébrique, à la manière proposé par Cassini: l'année zéro existe et les années précédant celle-ci sont notées en nombre négatif.

Or le calendrier 'iso8601' ne suit pas exactement cette norme. Il se contente d'imiter strictement le calendrier 'gregory'. Depuis le version 46 de CLDR (octobre 2024), les outils Unicode tendent à rapprocher le calendrier 'iso8601' de la norme, le distinguant donc de 'gregory'. Dans la version mise en oeuvre par Firefox mi-2025, les dates du calendrier 'iso8601' sont présentées en poids forts d'abord, se rapprochant du format normalisé AAAA-MM-JJ. Toutefois les années avant l'ère chrétienne sont encore représentées en notation rétrograde (1 av. J.-C. etc.). Le présent outil permet de détecter les progrès de la présentation Unicode dans les différents navigateurs.

Une option permet de spécifier que l'ère doit être masquée, ou qu'elle doit apparaître de manière complète ou plus ou moins abrégée ("av. J.-C." ou "avant Jésus-Christ"). Or, dans les versions qu'Unicode met à disposition depuis début 2020, quand l'option est absente, elle peut être arbitrairement modifiée, et l'ère apparaît alors que l'utilisateur ne la demandait pas. Plus précisément, l'ère est affichée dès que l'année l'est, pour les calendriers autres que le grégorien, le chinois et le coréen, même si l'utilisateur ne l'a pas demandé. Dans certaines versions des ICU Unicode, il pouvait y avoir des exceptions avec certaines langues, dont l'anglais du Royaume-Uni.

Nous avons fait deux propositions en avril 2020:

Une incohérence est visible dans la présentation des années antérieures à l'an 8, année origine dite "de l'Incarnation" dans le calendrier éthiopien Amete Mihret. Quand ils écrivent une date antérieure à l'année de l'Incarnation, les Ethiopiens décomptent l'année à partir de l'origine du monde (Amete Alem), 5500 ans avant l'Incarnation. Ils ne décomptent ni en relatif (avec des années négatives), ni en rétrograde à partir de l'Incarnation.

L'ère antérieure à l'Incarnation est donc l'ère de l'origine du monde, ou l'ère Amete Alem, et non pas, comme l'affiche la variante française, "avant l'Incarnation". Cette expression malheureuse peut provoquer des erreurs de compréhension.

La question a été signalée à Unicode en avril 2020, la modification des données est planifiée.

La méthode Javascript toISOString affiche un objet Date selon la norme ISO 8601. Cette fonction n'est disponible que depuis récemment, et une fonction d'émulation était proposée dans l'attente de sa diffusion définitive. Hélas, la fonction d'émulation était incorrecte.

Un certain nombre de CMS, dont celui que nous utilisons ici, n'ont pas retiré leur fonction d'émulation incorrecte de leur environnement, et vous observerez que l'affichage ISO n'est pas conforme pour les années inférieures à 1000. L'année doit toujours comporter 4 ou 6 caractères.

Ce dysfonctionnement a été signalé le 6 janvier 2020 à l'éditeur du présent CMS.

Ce genre de problème est l'une des raisons pour lesquelles nous présentons l'application sur cette page GitHub.