Temporal, le parcours de 9 ans qui a résolu le problème du temps en JavaScript

• La nouvelle norme Temporal API, qui remplace en profondeur les limites de l’objet Date en JavaScript, a atteint le stade 4 d’ECMAScript après 9 ans de développement
• Temporal fournit des types immuables, une prise en charge explicite des fuseaux horaires et des calendriers, ainsi qu’une précision à la nanoseconde, éliminant les ambiguïtés et les erreurs de l’ancien Date
• Bloomberg, Igalia, Microsoft, Google, Mozilla et d’autres acteurs ont collaboré à la conception de la spécification et à son implémentation, avec la bibliothèque commune en Rust temporal_rs pour permettre une coopération entre plusieurs moteurs
• Temporal prend en charge avec précision les calculs temporels et les calendriers internationaux grâce à des types détaillés comme ZonedDateTime, Instant, PlainDate/Time, Duration
• Cette norme, qui résout des problèmes vieux de 30 ans, est considérée comme un exemple réussi de collaboration et d’innovation ouverte dans l’écosystème JavaScript

---

Les problèmes de gestion du temps en JavaScript et l’arrivée de Temporal

• L’ancien objet Date, simple portage du Date de Java en 1995, est depuis des décennies une source de bugs à cause de sa mutabilité, de calculs de mois incohérents et d’un parsing ambigu
  • Exemple : erreurs de calcul en fin de mois avec setMonth, résultats différents selon les navigateurs lors du parsing de chaînes proches du format ISO
• À partir des années 2010, à mesure que les applications web se sont complexifiées, les limites de Date se sont aggravées
• Les développeurs ont compensé avec des bibliothèques externes comme Moment.js, au prix d’une augmentation de la taille des bundles et d’une charge de maintenance supplémentaire
• En 2017, Maggie Johnson-Pint a soumis à TC39 la proposition Temporal, lançant le processus de standardisation

La collaboration entre TC39 et l’industrie

• Temporal a commencé en stage 1 en 2018 et a atteint le stage 4 (standardisation) au terme d’un parcours de 9 ans
• Bloomberg a participé activement pour résoudre les problèmes de fuseau horaire et de précision dans des environnements JavaScript à grande échelle
  • Exigences : fuseaux horaires personnalisés, exactitude historique basée sur l’IANA, précision à la nanoseconde
• La spécification et l’implémentation ont été menées en collaboration avec Igalia, Microsoft, Google, Mozilla et d’autres
• Plusieurs ingénieurs ont participé comme champions, dont Philipp Dunkel, Ujjwal Sharma, Philip Chimento, Shane Carr, Justin Grant

Les principaux types et fonctionnalités de Temporal

• Temporal.ZonedDateTime : représentation immuable d’un instant avec fuseau horaire, calendrier et ajustement explicite de l’heure d’été
  • Exemple : lors du passage à l’heure d’été à Londres, si 01:30 n’existe pas, la valeur est automatiquement ajustée à 02:30
• Temporal.Instant : représentation d’un instant absolu sans fuseau horaire ni calendrier, avec précision à la nanoseconde
  • Le même instant peut être converti vers plusieurs fuseaux horaires
• PlainDate / PlainTime / PlainDateTime / PlainYearMonth / PlainMonthDay : types « horloge murale » sans fuseau horaire
  • Adaptés à l’affichage simple de dates et heures ou à leurs calculs
• Temporal.Duration : représentation d’un intervalle de temps, avec conversion possible entre différentes unités (total({ unit: "second" }))
• Prise en charge des calendriers : exécution correcte d’opérations sur des calendriers non grégoriens, comme le calendrier hébraïque

Implémentation et processus de standardisation

• Temporal constitue l’ajout de spécification le plus important de l’histoire d’ECMAScript, avec environ 4 500 cas de test
• Une implémentation commune en Rust, temporal_rs, a été développée et utilisée conjointement par plusieurs moteurs comme V8 et Boa
  • Avantages : réduction de la barrière à l’entrée, maintenance à long terme facilitée, amélioration de la qualité du code
• Entre 2024 et 2025, temporal_rs a atteint 100 % de réussite aux tests et est considéré comme un exemple réussi de collaboration multi-moteurs

État du support et défis à venir

• Temporal est déjà pris en charge par Firefox 139, Chrome/Edge 144 et TypeScript 6.0 Beta
  • Safari en est au stade de préversion technique, et Node.js 26 est prévu
• Le principal défi à venir est l’intégration avec les API Web
  • Exemple : prise en charge des types Temporal dans les éléments de formulaire comme <input type="date">
  • Étude de son potentiel pour remplacer DOMHighResTimeStamp (avec l’exemple d’utilisation de Temporal.Now.instant())

Les résultats de la collaboration et de l’innovation ouverte

• Temporal est une norme finalisée grâce à 9 années de collaboration entre plusieurs organisations, avec la participation de
  • Microsoft, Google, Mozilla, Bloomberg, Igalia, Boa et d’autres acteurs
• temporal_rs est considéré comme un exemple réussi de modèle d’infrastructure partagée, qui a
  • réduit les coûts d’implémentation redondants, amélioré la cohérence et accéléré l’innovation
• Au-delà d’une simple amélioration d’API, Temporal est vu comme la preuve d’un effort collectif de la communauté JavaScript pour résorber une dette technique de long terme
• Après 30 ans, JavaScript dispose enfin d’une API moderne pour les dates et les heures

[jeeeyul]

La complexité des calculs temporels vient bien plus de la philosophie humaine, de la précision de l’astronomie et de la culture que d’un simple problème de format. Le calcul, lui, est facile même avec un simple long. Historiquement, sur la ligne du temps, il existe de nombreuses zones particulières où 1 + 1 ne fait pas 2, et cela vient en grande partie des calendriers, comparables au I Ching, qui varient selon la position, comme l’angle du soleil et de la surface terrestre. Dans ce genre de cas, le calendrier luni-solaire coréen n’a jamais même été pris en compte dans la discussion.

Et c’est l’Institut coréen de recherche en astronomie et sciences spatiales qui le détermine.

[tsboard]

Enfin ! Quel bonheur !!

[shakespeares]

Enfin !!

[roxie]

ZonedDateTime...? Ne me dis pas que toi aussi... !

[sea715]

Enfin.

[click]

Le parcours est donc le suivant.

C time.h -> Java java.util.Date -> Date de JS

joda-time de Java -> JSR 310 -> java.time
-> moment.js -> Temporal de JS

[GN⁺]

Commentaires sur Hacker News

• J’aime vraiment le fait que Temporal impose de traiter correctement la complexité de la gestion du temps
  La distinction entre un instant et un datetime basé sur le calendrier permet d’éviter presque toutes les erreurs courantes avec Date
  C’est un peu verbeux, mais c’est bien mieux que d’être réveillé à 3 heures du matin pour corriger un bug lié à l’heure d’été
  • Techniquement parlant, il est peu probable qu’on ait à corriger un bug DST à 3 heures du matin un autre jour que le dimanche
• Moi aussi, j’ai galéré pendant presque 10 ans avec le parsing des dates ISO8601 en Python
  Un ticket ouvert en 2012 a fini par déboucher sur une solution intégrée à la bibliothèque standard
  La discussion associée est visible dans ce fil Google Groups
  • Merci sincèrement. Parser des dates autrement qu’avec fromisoformat me paraît maintenant tellement contre-intuitif
    Avant, j’utilisais ciso8601, mais depuis que c’est dans la bibliothèque standard, c’est beaucoup plus simple et plus fiable
• Le fait que Firefox ait pu implémenter Temporal dès l’étape de spécification est dû à André Bargull (Anba),
  et c’est particulièrement impressionnant de savoir qu’il a en réalité tout implémenté seul en tant que bénévole
• Temporal est une grande avancée, mais je n’aime toujours pas l’API
  Comme je partage du code entre client et serveur, j’essaie de séparer strictement les données de la logique
  Je veux garder toutes les données en JSON pur pour faciliter la sérialisation/désérialisation, mais les objets Temporal sont des instances de classes avec des propriétés de fonction, ce qui est peu pratique
  Je préfère une approche à la date-fns, où des fonctions pures s’appliquent à des objets uniquement dédiés aux données
  • C’est un choix de conception délibéré. Les types Temporal sont sérialisables, mais ne sont pas restaurés automatiquement par JSON.parse
    Le développeur doit reconstruire lui-même l’objet approprié à partir de la chaîne ISO
    Automatiser cela ferait courir le risque de manipuler le mauvais type
    L’exemple de reviver Temporal.Instant dans la documentation peut être utile
  • Je rencontre souvent le même problème. Le fait que JSON.parse/stringify fasse disparaître le prototype est un souci classique
    Mais je pense que l’équipe Temporal a fait le bon choix. Pour la logique date/heure, la sûreté de typage est plus importante qu’une simple approche données + fonctions
    Lier les opérations aux objets permet d’éviter qu’un PlainDate soit traité par erreur comme un ZonedDateTime
    Avec quelque chose comme tRPC, il suffit d’ajouter une fine couche qui convertit avec Temporal.from() et toString() aux frontières
    C’est un peu fastidieux, mais c’est préférable à abandonner la sûreté de typage
  • En réalité, les instances Date de JavaScript ont exactement le même problème
    Date.toJSON existe, mais lors du parsing JSON, il faut reconvertir la chaîne en Date
    Temporal fonctionne pareil, et date-fns manipule au final lui aussi des instances Date natives
  • Tous les objets Temporal peuvent être sérialisés/désérialisés facilement avec .toString() et Temporal.from()
  • Je pense que modifier JSON.parse pour qu’il crée automatiquement des objets Temporal serait excessif
    Comme pour Date

    serialize: instant.toJSON()
    deserialize: Temporal.Instant.from(jsonDate)
    

    il est normal de le gérer explicitement de cette manière
• Je suis vraiment ravi que Temporal ait été approuvé
  Félicitations à tous les champions qui ont travaillé dessus pendant si longtemps
  J’ai pris beaucoup de plaisir à travailler sur temporal_rs ces dernières années
• Il aurait été intéressant de mentionner aussi le parcours d’amélioration de l’API temporelle en Java (Joda-Time → JSR 310 → Java 8)
  Comme la proposition radicale de JavaScript est arrivée en 2018, je me demande dans quelle mesure l’approche de Java a pu influencer le résultat
  • Oui, il est juste de voir les choses ainsi : Joda a influencé Moment.js, qui a ensuite nourri les discussions de TC39
    TC39 s’est appuyé sur les précédents d’autres langages, tout en trouvant un consensus adapté à JavaScript
    Je pense que cette API est l’implémentation la plus aboutie conçue par des experts JS au cours de ces 9 années
  • Oui, JavaScript avait lui aussi repris de Java une mauvaise version de Date
    On peut voir des détails à ce sujet dans ce fil HN
• La remarque « à l’époque de Mocha, Ken Smith a porté en C le code Date de Java » est amusante
  parce que util.Date de Java était lui-même presque un port de l’API time.h du C
• Voir que Safari prend Temporal en charge partiellement m’a fait rire
  On dirait que Safari est devenu le successeur spirituel d’IE
  • Safari est lent à adopter les nouvelles fonctionnalités, mais les implémente malgré tout régulièrement
    Le problème d’IE n’était pas la lenteur, mais le fait de s’être arrêté depuis une position dominante
    Aujourd’hui, c’est Chrome qui occupe la place de l’empire, et Safari comme Firefox sont au contraire plus nécessaires que jamais
    Le vrai problème, c’est la multiplication des sites réservés à Chrome
  • Même en 2026, j’ai l’impression qu’il n’y aura toujours pas de sélecteur de date natif sur Safari mobile
• J’aimerais que Temporal ait un type intervalle

  const D = new Temporal()
  const t = new Interval({minutes:5})
  const v = D.add(t)
  

  • C’est Duration

    const D = Temporal.PlainDate.from("2020-06-16");
    const t = Temporal.Duration.from({ day: 1 });
    const v = D.add(t) // 2020-06-17
    

    Voir la documentation MDN
  • Oui, ça s’appelle Duration
• Merci à l’équipe d’avoir fait du voyage dans le temps à vitesse réelle pendant 9 ans pour rendre ça possible