Siempre utilizo marcas de tiempo Unix para todo, pero me pregunto si hay una mejor manera.¿Las marcas de tiempo de Unix son la mejor manera de almacenar marcas de tiempo?
¿Qué se usa para almacenar marcas de tiempo y por qué?
Independientemente de cómo elija almacenar una marca de tiempo, es importante evitar los problemas de interpretación regional y los problemas de compensación de tiempo. Una marca de tiempo de Unix se interpreta igual independientemente de la región, y se calcula a partir del mismo punto en el tiempo independientemente de la zona horaria: estas son cosas buenas.
Tenga cuidado al almacenar las marcas de tiempo como cadenas ambiguas como 01/02/2008, ya que pueden interpretarse como el 2 de enero de 2008 o el 1 de febrero de 2008, dependiendo de la configuración regional.
Al almacenar horas/minutos/segundos, es importante saber "qué" hora/minuto/segundo se está especificando. Puede hacerlo incluyendo información de zona horaria (no necesaria para una marca de tiempo Unix, ya que se supone que es UTC).
Sin embargo, tenga en cuenta que las marcas de tiempo de Unix no pueden representar de manera única algunos instantes en el tiempo: cuando hay un segundo intercalar en UTC, la marca de tiempo de Unix no cambia, por lo que ambas 23:59:60 UTC y 00:00:00 la siguiente día tiene la misma representación de Unix. Entonces, si realmente necesita una resolución de un segundo o mejor, considere otro formato.
Si prefiere un formato de lectura más humano para el almacenamiento que una marca de tiempo Unix, considere ISO 8601.
Una técnica que ayuda a mantener las cosas claras es almacenar fechas como UTC y solo aplicar desplazamientos de zona horaria o DST al mostrar una fecha a un usuario.
32 bit Unix timestamps will overflow in a few years (January 2038), por lo que podría ser una consideración. Generalmente uso un formato DATETIME en SQL, que es AAAA-MM-DD HH: MM: SS con la hora como un reloj de 24 horas. Intento generar archivos en el mismo formato, solo para hacer mi vida más fácil.
¿Qué época es necesario almacenar ya qué resolución? Si necesita microsegundos, o fechas en el tiempo de la edad de piedra, podría no ser el mejor. Para propósitos comerciales generales, es bastante bueno (suponiendo 64 bits)
No tenían fechas en la Edad de Piedra, ¿verdad? –
Claro que lo hicieron - conoces a una linda chica, la golpeas en la cabeza y la arrastras de vuelta a tu cueva - muy romántico ... –
Necesitas calcular fechas/horas durante períodos largos para cosas como eventos astronómicos (eclipses, etc.) el sistema para esto (días julianos) comienza alrededor de 5000bc –
estilo-tiempo (time_t + microsegundos) si necesito una precisión inferior a la del segundo, sino solo time_t. Puede usar un valor entero de 64 bits para almacenar time_t * 1000000 + usec y tiene una prueba de desbordamiento durante más de +/- 292,000 años.
Esa es una muy buena idea. –
Una marca de tiempo es Bascially:
Y como un punto en el tiempo tiene una resolución sin fin, lo importante en la elección de un formato de hora es: tiene lo suficiente ¿resolución?
Para la mayoría de las aplicaciones que tenía, eran lo suficientemente nanosegundos. Así que Java Timestamp tenía la resolución correcta para mí hasta ahora.
Depende de para qué necesita las marcas de tiempo.
Un timestamp de unix no puede representar el tiempo 1 segundo después de 2008-12-31T23: 59: 59Z. Si '2009-01-01T09: 00: 00' - '2008-12-31T09: 00: 00' con marcas de tiempo de UNIX el resultado NO es correcto: habrá un segundo intercalado entre esas dos fechas y están separados por 86401 segundos (no 86400 como marcas de tiempo Unix le dirá).
Aparte de eso, y lo que los otros responden, sí - las marcas de tiempo UNIX son el camino a seguir :)
Una marca de tiempo no es una buena idea sobre las bases de datos, ya que no toman el horario de verano o la corriente hora local en cuenta. En MySQL es mejor almacenarlo como una hora, y luego usar el MySQL date and time functions para recuperar las partes que desea o comparar con otras fechas.
Si está almacenando un archivo de registro, por favor, para el amor de Pete, que sea algo legible y léxico.
2008-10-07 09:47:02 por ejemplo.
7 años después ... La lectura humana es excelente y estoy a favor, pero la fecha en este ejemplo es ambigua. Si realmente necesita saber cuándo sucedió algo, necesita información sobre la zona horaria, por lo que debe ir con algo como 2008-10-07T09: 47: 02Z para que pueda obtener legibilidad humana y un punto preciso en el tiempo. –
No es ambiguo. No hay '???? - ?? - ??'formato de fecha que no es' aaaa-mm-dd', es decir, ISO-8601 a excepción de la "T". –
Me gusta cómo tardó un minuto en hacer clic en el botón Publicar – Samus
UNIX Timestamp El problema de 32 bits parece ser bastante molesto para los usuarios que ingresan fechas futuras en 2038+.
O utilice la secuencia DATETIME para MySQL, o almacene sus fechas como BIGINT (8) sin firmar (máximo: 18 quintillones) o FLOAT para que pueda ingresar números grandes. Entonces no puede usar, por ejemplo, la función date() de PHP porque solo permite números enteros como parámetro (limitado por sistemas de 32 bits).
La solución que encontré es usar PHP 5.2.0 funciones. Here's the DateTime PHP solution.
No es necesario cambiar el formato UNIX_TIMESTAMP. Siempre que tenga BIGINT (8) sin firmar como su almacenamiento MySQL para marcas de tiempo. Ya no estará limitado por sistemas de 32 bits.
2038 para 32bit pero la mayoría de los sistemas son 64bit ahora –
es 2038 - http://en.wikipedia.org/wiki/Year_2038_problem – warren
Fijo y vinculado. @mgb - Sí, aunque creo que los sistemas integrados tendrán más problemas. –