Convertisseur date/heure

Un analyseur complet de date et heure qui gère les horodatages Unix, les dates ISO 8601, le format RFC 2822, les styles de date US/EU, les dates longues et les expressions relatives. Convertit entre les formats, affiche le temps relatif et fournit une référence d'horodatage actuel.

Specifications

• Unix Time - Wikipedia
• ISO 8601 Date Format
• RFC 2822 Date Format

Cas d'utilisation courants

• Déboguer les réponses API contenant des horodatages ou des dates
• Convertir les horodatages de fichiers de log en dates lisibles
• Analyser les dates de différents formats régionaux
• Calculer les différences de temps entre les événements
• Générer des horodatages pour les requêtes API
• Vérifier les temps d'expiration des jetons (revendication JWT exp)
• Convertir entre les formats de date pour les équipes internationales

Fonctionnalites

• Détection automatique du format : horodatages Unix, ISO 8601, RFC 2822, dates US/EU et plus
• Analyser les horodatages Unix en secondes, millisecondes, microsecondes ou nanosecondes
• Gérer les dates ISO 8601 avec ou sans heure (2024-01-25T12:00:00Z)
• Analyser le format US (01/25/2024), le format EU (25.01.2024) et les dates longues (January 25, 2024)
• Reconnaître les expressions relatives : now, today, yesterday, tomorrow
• Afficher le temps relatif ("il y a 2 heures", "dans 3 jours")
• Badges de statut Passé/Futur/Aujourd'hui
• Afficher le jour de la semaine, le numéro de semaine, le trimestre et le jour de l'année
• Grille de métriques calendaires (semaine de l'année, trimestre, jour de l'année)
• Section d'informations supplémentaires (fuseau horaire, jours dans le mois, année bissextile)
• Convertir vers plusieurs formats de sortie avec boutons de copie
• Sortie en microsecondes et nanosecondes Unix
• Carte de référence de l'heure actuelle avec bouton d'actualisation

Exemples

1706188800

1706188800000

2024-01-25T12:00:00Z

2024-01-25

01/25/2024

25.01.2024

January 25, 2024

now

Conseils

• JavaScript Date.now() retourne des millisecondes ; la plupart des outils Unix utilisent des secondes.
• Le format ISO 8601 (2024-01-25T12:00:00Z) est le format le plus portable et non ambigu.
• Utilisez des horodatages UTC pour le stockage ; convertissez en heure locale uniquement pour l'affichage.
• Quand une date est ambiguë (ex. : 01/02/2024), l'outil utilise des indices contextuels pour déterminer le format.
• Le "problème de l'année 2038" affecte les systèmes 32 bits utilisant des entiers signés pour les secondes Unix.

Comprendre Convertisseur date/heure

Unix timestamps represent a specific moment in time as the number of seconds elapsed since the Unix epoch: January 1, 1970, at 00:00:00 UTC. This simple integer representation is the universal time format in computing, used by databases, APIs, file systems, log files, and operating system interfaces. The format is unambiguous — unlike human-readable dates, a Unix timestamp always refers to exactly one moment in time regardless of timezone.

Two precision levels are common. Second-precision timestamps (10 digits, like 1738800000) are the traditional Unix format used by most Unix APIs, databases, and the C time() function. Millisecond-precision timestamps (13 digits, like 1738800000000) are used by JavaScript (Date.now()), Java (System.currentTimeMillis()), and many web APIs. This tool auto-detects the precision and handles both correctly.

ISO 8601 is the standard human-readable date-time format: 2025-02-05T12:00:00Z. The T separates date and time, and Z indicates UTC (Zulu time). Timezone offsets use +HH:MM or -HH:MM notation. ISO 8601 is required by JSON Schema, widely used in REST APIs, and recommended for any date-time string interchange. RFC 2822 format (used in email headers) is another common text representation.

Timezone handling is the most common source of date-time bugs. Developers frequently confuse UTC timestamps with local times, apply timezone conversions incorrectly, or store local times without timezone information. Best practice is to always store and transmit times in UTC, converting to local time only for display.

Systems storing Unix timestamps as 32-bit signed integers will overflow on January 19, 2038, at 03:14:07 UTC, wrapping to a negative number that represents December 1901. This is analogous to Y2K but affects computing infrastructure more broadly. The fix is to use 64-bit integers, which extends the range to billions of years. Most modern systems already use 64-bit time, but embedded systems and legacy code may still be vulnerable.

When choosing between storing dates as timestamps or formatted strings, consider the use case. Timestamps (integers) are ideal for computation-heavy scenarios like sorting, calculating durations, and comparing dates — they are compact, unambiguous, and timezone-neutral. ISO 8601 strings are preferable when human readability matters, when timezone context must be preserved, or when the database has native datetime types. PostgreSQL's timestamptz, for example, stores UTC internally and converts for display.

Dates that appear to be off by one day are almost always caused by timezone confusion. A UTC timestamp for February 5 at 23:00 UTC is already February 6 in UTC+2 timezones. In JavaScript, Date() uses local time for date-only strings but UTC for datetime strings with timezone designators. Being explicit about timezones and consistently using UTC for storage and transmission prevents these subtle bugs.