Convertisseur Date/Heure

Que sont les formats de date ?

Un format de date definit la maniere dont une valeur de date et/ou d’heure est representee sous forme de texte. Le meme instant — disons, le quinze mars 2024 a quatorze heures trente a Londres — peut etre ecrit de dizaines de facons selon le format, la locale et le fuseau horaire :

• 2024-03-15T14:30:00Z (ISO 8601)
• 1710513000 (horodatage Unix)
• Fri, 15 Mar 2024 14:30:00 +0000 (RFC 2822)
• 03/15/2024 2:30 PM (format americain)
• 15/03/2024 14:30 (format europeen)
• 2024年3月15日 14時30分 (japonais)

La conversion de format de date transforme les horodatages entre ces representations. C’est essentiel pour l’echange de donnees entre systemes, API, bases de donnees et interfaces utilisateur qui attendent chacun des formats differents.

ISO 8601 : le standard universel

ISO 8601 est la norme internationale pour la representation des dates et heures. Elle utilise un format strict et non ambigu qui elimine la confusion entre l’ordre americain et europeen des dates :

YYYY-MM-DDThh:mm:ss±hh:mm
2024-03-15T14:30:00+01:00

Proprietes cles d’ISO 8601 :

• Annee en premier : Elimine l’ambiguite JJ/MM vs MM/JJ
• Separateur T : Separe clairement la date de l’heure
• Decalage de fuseau horaire : Indique explicitement le decalage par rapport a UTC
• Suffixe Z : Abreviation pour UTC (decalage zero)
• Tri lexicographique : Les chaines ISO 8601 se trient correctement comme du texte brut

ISO 8601 est le format par defaut pour les API JSON, la methode Date.toISOString() de JavaScript, PostgreSQL et la plupart des standards modernes d’echange de donnees.

Horodatages Unix

Un horodatage Unix (egalement appele temps epoch ou temps POSIX) represente un instant comme le nombre de secondes ecoulees depuis le 1er janvier 1970 00:00:00 UTC — l’epoque Unix.

1710513000 = 2024-03-15T14:30:00Z

Les horodatages Unix sont compacts, non ambigus, neutres en termes de fuseau horaire (toujours en UTC) et trivialement comparables (simple comparaison d’entiers). Ils constituent la representation interne standard du temps dans la plupart des langages de programmation et des bases de donnees.

Variante	Unite	Plage	Debordement
Unix (32 bits)	Secondes	1970 - 2038	19 janv. 2038
Unix (64 bits)	Secondes	1970 - 292 milliards d’annees	Jamais (en pratique)
Millisecondes	ms	1970 - futur lointain	Standard JavaScript
Microsecondes	us	1970 - futur lointain	PostgreSQL, Python

JavaScript utilise les millisecondes depuis l’epoque (Date.now() renvoie des millisecondes). De nombreuses API et bases de donnees utilisent les secondes. Verifiez toujours quelle unite votre systeme attend.

Reference des formats

Format	Exemple	Utilise par
ISO 8601	2024-03-15T14:30:00Z	API, JSON, bases de donnees
Unix (secondes)	1710513000	Composants systeme, journalisation
Unix (millisecondes)	1710513000000	JavaScript, Java
RFC 2822	Fri, 15 Mar 2024 14:30:00 +0000	En-tetes d’email, HTTP
Lisible par l’humain	March 15, 2024 2:30 PM EST	Affichage UI, rapports
SQL	2024-03-15 14:30:00	Bases de donnees (sans T, sans Z)

Fuseaux horaires et UTC

Les fuseaux horaires sont la source numero un de bugs lies aux dates et heures. Il existe plus de 400 identifiants de fuseaux horaires dans la base de donnees IANA, et ils changent regulierement — des pays adoptent, modifient ou abolissent l’heure d’ete, decalent leur offset UTC ou se divisent en nouvelles zones.

Ecueils principaux :

• Transitions d’heure d’ete : Les horloges « avancent » (perdant une heure) et « reculent » (gagnant une heure). Un horodatage comme « 2024-03-10 02:30 America/New_York » n’existe pas — les horloges sont passees de 2h00 a 3h00.
• Les abreviations de fuseaux horaires sont ambigues : « CST » designe Central Standard Time (UTC-6), China Standard Time (UTC+8) et Cuba Standard Time (UTC-5). Utilisez toujours les identifiants IANA (America/Chicago, Asia/Shanghai).
• Decalages non entiers : L’Inde est a UTC+5:30, le Nepal a UTC+5:45 et les iles Chatham (Nouvelle-Zelande) a UTC+12:45.

Ecueils courants

1. Stocker l’heure locale sans fuseau horaire. Un simple 2024-03-15 14:30:00 est denue de sens sans savoir a quel fuseau horaire il fait reference. Stockez toujours en UTC ou incluez le decalage.

2. Supposer que chaque jour fait 24 heures. Les transitions d’heure d’ete creent des jours de 23 heures et de 25 heures. L’arithmetique temporelle qui ajoute 86400 secondes pour avancer d’un jour sera incorrecte deux fois par an.

3. Utiliser les abreviations de fuseaux horaires. « PST » et « PDT » sont des decalages differents. Utilisez America/Los_Angeles et laissez la bibliotheque determiner le decalage correct pour une date donnee.

4. Ignorer les secondes intercalaires. L’UTC ajoute occasionnellement une seconde intercalaire (23:59:60). La plupart des systemes ignorent les secondes intercalaires, mais le temps GPS, le NTP et certains systemes financiers en tiennent compte.

Cas d’usage courants

• Integration d’API : Convertir les horodatages entre le format renvoye par votre API (ISO 8601, Unix) et le format attendu par votre base de donnees ou votre frontend
• Correlation de journaux : Convertir les horodatages de differents services (chacun potentiellement dans des formats et fuseaux horaires differents) vers un format commun pour une analyse unifiee des journaux
• Planification inter-fuseaux horaires : Convertir les horaires de reunion, les fenetres de deploiement ou les planifications de maintenance entre les heures locales des membres de l’equipe
• Migration de donnees : Transformer les colonnes de date lors du deplacement de donnees entre des bases de donnees avec des formats d’horodatage differents (epoque Unix dans Redis vs ISO 8601 dans PostgreSQL)
• Debogage de bugs temporels : Convertir les horodatages Unix des journaux d’erreurs en dates lisibles pour comprendre quand les evenements se sont produits