timestampinfo.fr
Outils & documentation

LA DOCUMENTATION DU TEMPS

Le problème de l’an 2038

Comprendre la limite d’un timestamp Unix stocké dans un entier signé de 32 bits.

La dernière seconde représentable

Un entier signé de 32 bits peut représenter au maximum 2 147 483 647. Interprétée comme des secondes Unix, cette valeur correspond au 19 janvier 2038 à 03:14:07 UTC.

Le premier instant hors plage est le 19 janvier 2038 à 03:14:08 UTC, soit 2 147 483 648 secondes.

Que se passe-t-il lors du dépassement ?

Si un système reboucle vers l’entier signé minimal, la valeur devient −2 147 483 648, correspondant au 13 décembre 1901 à 20:45:52 UTC. Ce comportement n’est pas universel : une application peut aussi signaler une erreur, saturer la valeur ou avoir un comportement indéfini selon le langage et l’opération.

new Date(2147483647 * 1000).toISOString();
// 2038-01-19T03:14:07.000Z

new Date(2147483648 * 1000).toISOString();
// 2038-01-19T03:14:08.000Z

JavaScript Date ne rencontre pas cette limite : son stockage n’est pas un entier signé de 32 bits en secondes.

Quels systèmes vérifier ?

  • Les applications et bibliothèques qui utilisent encore des dates sur 32 bits.
  • Les formats de fichiers, protocoles et champs de bases qui imposent cette taille.
  • Les systèmes embarqués et les échanges avec des logiciels anciens.

Un processeur 64 bits ne corrige pas à lui seul un champ de protocole resté sur 32 bits. À l’inverse, certaines plateformes 32 bits prennent en charge un time_t de 64 bits.

Comment préparer une migration ?

Inventoriez les représentations de dates, utilisez les types adaptés à la plateforme, puis testez l’écriture, la lecture et les échanges autour de la limite. Ajoutez des dates avant 1970 et après 2038 pour détecter les conversions implicites. Les mécanismes de compatibilité varient selon le système et la bibliothèque.

Références

GNU libc — gestion du temps sur 64 bits · Plage des dates JavaScript

Ouvrir le convertisseur