Les horodatages Unix sont-ils le meilleur moyen de stocker les horodatages?

J’utilise toujours des horodatages Unix pour tout, mais je me demande s’il existe une meilleure solution.

Qu’est-ce que vous utilisez pour stocker les horodatages et pourquoi?

Quoi qu’il en soit, il est important d’éviter les problèmes d’interprétation régionaux et les problèmes de décalage temporel. Un horodatage Unix est interprété de la même manière, quelle que soit la région, et est calculé à partir du même point temporel, indépendamment du fuseau horaire. Ce sont de bonnes choses.

Prenez garde à stocker les horodatages en tant que chaînes ambiguës, telles que 01/02/2008, car cela peut être interprété comme le 02 janvier 2008 ou le 01 février 2008, en fonction de la localisation.

Lors du stockage des heures / minutes / secondes, il est important de savoir “quelle” heure / minute / seconde est spécifiée. Vous pouvez le faire en incluant des informations de fuseau horaire (non nécessaires pour un horodatage Unix, car il est supposé être UTC).

Cependant, notez que les horodatages Unix ne peuvent pas représenter de manière unique certains instants dans le temps: quand il y a une seconde de saut dans l’UTC, l’horodatage Unix ne change pas, donc 23:59:60 UTC et 00:00:00 le jour suivant Représentation Unix. Donc, si vous avez vraiment besoin d’une résolution d’au moins une seconde, considérez un autre format.

Si vous préférez un format plus lisible pour l’homme qu’un timestamp Unix, prenez en compte ISO 8601 .

Une technique qui permet de garder les choses simples est de stocker les dates sous forme d’UTC et d’appliquer uniquement les décalages horaires ou DST lors de l’affichage d’une date à un utilisateur.

Si vous stockez un fichier journal, s’il vous plait, pour l’amour de pete, faites-en quelque chose de lisible par l’homme et de sorting lexical.

2008-10-07 09:47:02 par exemple.

Les horodatages Unix 32 bits déborderont dans quelques années (janvier 2038) , cela pourrait donc être une considération. J’utilise généralement un format DATETIME en SQL, qui est AAAA-MM-JJ HH: MM: SS avec l’heure sous la forme d’une horloge de 24 heures. J’essaie de générer des fichiers dans le même format, simplement pour me simplifier la vie.

De quelle époque avez-vous besoin pour stocker et à quelle résolution? Si vous avez besoin de microsecondes ou de dates dans l’âge de pierre, ce n’est peut-être pas la meilleure. Pour des raisons commerciales générales, c’est assez bon (en supposant 64 bits)

Cela dépend de ce dont vous avez besoin des horodatages.

Un horodatage unix ne peut pas représenter le temps 1 seconde après le 31 décembre 2008-12-18T23: 59: 59Z. Si vous faites ‘2009-01-01T09: 00: 00’ – ‘2008-12-31T09: 00: 00’ avec un horodatage Unix, le résultat n’est PAS correct: il y aura un saut entre ces deux dates et elles seront séparées par 86401 secondes (pas 86400 comme les horodatages unix vous le diront).

Autre que cela et ce que les autres intervenants ont dit, oui – les timestamps Unix sont la voie à suivre 🙂

Un horodatage n’est pas une bonne idée sur les bases de données, car elles ne tiennent pas compte de l’heure d’été ou de l’heure locale actuelle. Sur MySQL, il est préférable de le stocker comme une heure, puis d’utiliser les fonctions de date et d’heure de MySQL pour récupérer les parties souhaitées ou les comparer à d’autres dates.

timeval-style (time_t + microsecondes) si j’ai besoin d’une précision inférieure à la seconde, sinon juste time_t. Vous pouvez utiliser une valeur entière de 64 bits pour stocker time_t * 1000000 + usec et vous êtes protégé contre les débordements pendant plus de +/- 292 000 ans.

UNIX Timestamp Le problème de 32 bits semble être assez ennuyeux pour les utilisateurs qui entrent dans des dates futures en 2038 et plus.

Utilisez la séquence DATETIME pour MySQL ou stockez vos dates sous la forme BIGINT (8) non signé (max: 18 quintillions) ou FLOAT pour pouvoir entrer des nombres importants. Ensuite, vous ne pouvez pas utiliser par exemple la fonction date () de PHP car elle n’autorise que les entiers comme paramètre (limité par les systèmes 32 bits).

La solution que j’ai trouvée consiste à utiliser les fonctions PHP 5.2.0 . Voici la solution PHP DateTime .

Pas besoin de changer le format UNIX_TIMESTAMP. Tant que vous avez BIGINT (8) non signé comme stockage MySQL pour les horodatages. Vous ne serez plus limité par les systèmes 32 bits.

Un horodatage est de base:

  • un point distinct dans le temps

Et comme un point dans le temps a une résolution sans fin, l’important sur le choix d’un format d’horodatage est le suivant: a-t-il une résolution suffisante?

  • Le temps Unix compte seulement en secondes.
  • Ext 4 a des nanosecondes
  • Java a des nanosecondes

Pour la plupart des applications que j’avais, les nanosecondes suffisaient. Donc, Java Timestamp a eu la bonne résolution pour moi jusqu’à présent.