Générateur de mots de passe
Mots de passe et phrases de passe robustes.
Utilitaires
Convertir un horodatage en date lisible.
La première question devant tout horodatage, et il existe un repère simple.
Les horodatages Unix classiques comptent des secondes et comportent dix chiffres. JavaScript et beaucoup de systèmes récents comptent des millisecondes, ce qui donne treize chiffres.
Lire un horodatage en millisecondes comme des secondes vous projette des dizaines de milliers d’années dans le futur. Dans l’autre sens, vous atterrissez vers 1970. Les deux erreurs sautent aux yeux dans le résultat.
Ce convertisseur reconnaît le cas d’après la longueur et indique l’hypothèse retenue.
Certains systèmes emploient des microsecondes ou des nanosecondes — seize ou dix-neuf chiffres. C’est plus rare.
Un horodatage est par définition en UTC. C’est sa force : un seul nombre, aucune discussion de fuseau.
La conversion en heure locale n’intervient qu’à l’affichage. C’est pourquoi l’heure française et l’UTC figurent ici toutes deux — une heure d’écart en hiver, deux en été.
La leçon pratique pour qui construit des systèmes : stockez les dates en horodatage ou explicitement en UTC, et ne convertissez qu’à l’affichage. Stocker de l’heure locale finit toujours par poser problème au passage à l’heure d’hiver, puisque cette nuit-là une heure existe deux fois.
Pensez aussi aux territoires d’outre-mer si votre système les concerne : la conversion vers « l’heure locale » n’y donne pas le même résultat qu’en métropole.
Tout est calculé dans cette page.
Dix chiffres pour des secondes, treize pour des millisecondes. C’est reconnu ici.
Toujours UTC. La conversion en heure locale n’a lieu qu’à l’affichage.
Une valeur en secondes lue comme des millisecondes, ou un horodatage nul.
En horodatage ou explicitement en UTC, avec conversion à l’affichage seulement.
À la fin de l’heure d’été, une heure existe deux fois.
Non.