Sont des timestamps unix la meilleure façon de conserver les horodateurs?

Question

J'ai toujours utiliser des timestamps unix pour tout, mais je me demande si il ya une meilleure façon.

Que voulez-vous utiliser pour stocker les horodatages et pourquoi?

Answer 1

Cependant, vous choisissez de stocker un horodatage, il est important d'éviter régionale des problèmes d'interprétation et le décalage de l'heure de problèmes. Un timestamp Unix est interprété de la même indépendamment de la région, et est calculée à partir de la même point dans le temps, peu importe l'heure de la zone - ce sont de bonnes choses.

Méfiez-vous de stocker les horodatages comme ambiguë des chaînes de caractères comme 01/02/2008, car cela peut être interprété comme 02 janvier 2008 ou 01 février 2008, en fonction des paramètres régionaux.

Lors du stockage des heures/minutes/secondes, il est important de savoir "qui" heure/minute/seconde est spécifié. Vous pouvez faire cela, y compris les informations de fuseau horaire (pas nécessaire pour un timestamp Unix, puisqu'il est supposé être UTC).

Toutefois, notez que les timestamps Unix ne peut pas représenter uniquement quelques instants dans le temps: quand il y a un saut de seconde en UTC, le timestamp Unix ne change pas, donc, à la fois à 23:59:60 UTC et l'00:00:00 le jour suivant, ont la même Unix représentation. Donc, si vous avez vraiment besoin d'un deuxième ou d'une meilleure résolution, pensez à un autre format.

Si vous préférez un format lisible par l'homme pour le stockage que d'un timestamp Unix, envisager la norme ISO 8601.

Une technique qui aide à garder les choses simple est de stocker des dates que l'UTC et ne s'appliquent fuseau horaire ou l'heure d'été décalages lors de l'affichage d'une date pour un utilisateur.

Answer 2

Si vous enregistrez un fichier journal, s'il vous plaît pour l'amour de pete faire quelque chose de lisible par l'homme et lexicalement-triables.

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

Answer 3

32 bits timestamps Unix débordement dans quelques années (janvier 2038), donc cela pourrait être une considération. J'utilise généralement un format DATETIME de SQL, qui est AAAA-MM-JJ HH:MM:SS avec le temps comme une horloge de 24 heures. J'essaie de sortie pour les fichiers dans le même format, juste pour rendre ma vie plus facile.

Answer 4

Quelle époque avez-vous besoin pour stocker et à quelle résolution? Si vous avez besoin de quelques microsecondes, ou des dates dans l'âge de pierre time_t peut-être pas le meilleur. Pour les fins générales de l'entreprise, il est tout à fait bonne (en supposant que 64bit)

Answer 5

Cela dépend de ce que vous avez besoin de la date et heure pour.

Un timestamp unix ne peut pas représenter un temps de 1 seconde après 2008-12-31T23:59:59Z. Si vous ne '2009-01-01T09:00:00' - '2008-12-31T09:00:00', avec des timestamps unix le résultat n'est PAS correct: il y aura un saut de seconde entre ces deux dates, et ils sont séparés par 86401 secondes (pas 86400 que les timestamps unix va vous le dire).

Autre que cela, et ce que les autres intervenants a dit, oui, les timestamps unix sont la voie à suivre :)