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

Question

J'utilise toujours les horodatages Unix pour tout, mais je me demande s'il existe un meilleur moyen.

Qu'utilisez-vous pour stocker les horodatages et pourquoi?

Answer 1

Quel que soit votre choix de stocker un horodatage, il est important d’éviter les problèmes d’interprétation régionale et les problèmes de décalage horaire. 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 instant quel que soit le fuseau horaire. Ce sont de bonnes choses.

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

Lorsque vous stockez les heures / minutes / secondes, il est important de savoir "lequel". heure / minute / seconde est en cours de spécification. Vous pouvez le faire en incluant des informations sur le fuseau horaire (non nécessaire pour un horodatage Unix, car il est supposé être au format 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 intercalaire en UTC, l'horodatage Unix ne change pas. 23:59:60 UTC et 00:00:00 le lendemain. avoir la même représentation Unix. Donc, si vous avez vraiment besoin d'une résolution d'une seconde ou plus, envisagez un autre format.

Si vous préférez un format de stockage plus lisible par l'homme qu'un horodatage Unix, pensez à ISO 8601 . .

Une technique qui permet de garder les choses simples consiste à stocker les dates au format UTC et à n’appliquer que des décalages de fuseau horaire ou DST lors de l’affichage d’une date à un utilisateur.

Answer 2

Si vous stockez un fichier journal, veuillez, par amour, en faire quelque chose de lisible par l'homme et pouvant être trié lexicalement.

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

Answer 3

l'horodatage Unix 32 bits débordera dans quelques années (janvier 2038) , de sorte que ê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 au format 24 heures. J'essaie de créer des fichiers au même format, simplement pour me simplifier la vie.

Answer 4

À quelle époque devez-vous stocker et à quelle résolution? Si vous avez besoin de microsecondes ou de dates de l'âge de pierre, time_t pourrait ne pas être le meilleur. Pour les affaires en général, c’est plutôt bon (en supposant que 64 bits)

Answer 5

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 2008-12-31T23: 59: 59Z. Si vous faites '2009-01-01T09: 00: 00' - '2008-12-31T09: 00: 00' avec des horodatages Unix, le résultat n'est PAS correct: il y aura une seconde intercalaire entre ces deux dates et elles seront séparées 86401 secondes (et non 86400 comme le diront les horodatages Unix).

En dehors de cela et de ce que les autres répondants ont dit, oui - les horodatages Unix sont la voie à suivre:)

Answer 6

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

Answer 7

timeval-style (time_t + microsecondes) si j'ai besoin d'une précision inférieure à la seconde, sinon 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.

Answer 8

Le problème de l'horodatage UNIX 32 bits semble assez gênant pour les utilisateurs qui entrent dans les dates à venir en 2038 +.

Utilisez la séquence DATETIME pour MySQL ou enregistrez vos dates au format BIGINT (8) non signé (maximum: 18 quintillions) ou FLOAT afin de pouvoir entrer des nombres élevés. Ensuite, vous ne pouvez pas utiliser, par exemple, la fonction date () de PHP car elle autorise uniquement les entiers en tant que paramètre (limité aux 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é en tant que stockage MySQL pour les horodatages. Vous ne serez plus limité par les systèmes 32 bits.

Answer 9

Un horodatage est essentiellement:

• un moment précis

Et comme la résolution à un moment donné est sans fin, l’important dans le choix d’un format d’horodatage est le suivant: la résolution est-elle suffisante?

• Le temps Unix ne compte qu'en secondes.
• poste 4 a nanosecondes
• Java a nanosecondes

Pour la plupart des applications que j'avais, les nanosecondes étaient suffisantes. Donc, Java Timestamp avait la bonne résolution pour moi jusqu'à présent.