SQlite: formato de columna para timestamp unix; Tipos enteros

Question

Problema original: ¿Cuál es el formato de columna correcto para una marca de tiempo de Unix?

La red está llena de confusión: algunas publicaciones afirman que SQLite no tiene tipos sin firmar, ya sea cualquiera, o con excepción del tipo int de 64 bits (pero hay ejemplos (contra) que invocan UNSIGNED INTEGER). La página de tipos de datos lo menciona solo en un gran ejemplo. También afirma que hay un entero de 6 bytes pero no le da un nombre. Parece que mis intentos con INTEGER son marcas de tiempo de Unix de tienda firmadas de 4 bytes firmadas como números negativos. He oído que algunos sistemas también devuelven las marcas de tiempo de 64 bits. OTOH No me gusta desperdiciar 4 bytes para almacenar 1 bit adicional (parte superior de la marca de tiempo), e incluso si tengo que elegir un formato de datos más grande, preferiría ir al de 6 bytes. Incluso he visto una publicación que afirma que la marca de tiempo SQLite Unix es del tipo REAL ...

Problema completo: ¿Podría alguien aclarar ese lío?

Answer 1

El tamaño de un entero

Todas las columnas de bases de datos SQLite son internamente de anchura variable. El file format almacena enteros en 1, 2, 3, 4, 6 u 8 bytes, dependiendo de qué tan grande es el número, más un byte en el encabezado para indicar el tamaño. Entonces, en total, las fechas Unix almacenadas como enteros tomarán 5 bytes hasta 2038-01-19 y 7 bytes después de eso.

Desde el punto de vista del usuario de la API C, todos los enteros están firmados de 64 bits.

El tipo de columna

No importa si usted declara su columna como entero, entero sin signo, BIGINT, o lo que sea.Anything with "INT" in it has integer affinity. Y, como se mencionó anteriormente, todos los enteros están firmados de 64 bits, pero normalmente no se almacenan de esa manera.

Answer 2

Mi preferencia sería para un entero de 64 bits. El caso clásico de un entero de 32 bits sin signo es con segundos desde que se agota el 1970-01-01 en 2038. Consulte http://en.wikipedia.org/wiki/Unix_time y http://en.wikipedia.org/wiki/Year_2038_problem. Con un entero sin signo de 64 bits, está seguro

Answer 3

Podría dar un ejemplo de lo que quiere decir con "Parece que mis intentos con INTEGER son marcas de tiempo de Unix firmadas en 4 bytes firmadas como números negativos".

Si no lo ha hecho, le sugiero que lea los documentos de SQLite en datatypes (sección 1.2 Fecha y hora de tipo de datos) y date and time functions.

Answer 4

Si se encuentra en un sistema integrado donde la situación de la memoria es crítica, puede considerar eliminar la precisión cambiando el valor de 64 bits varios bits (resultando en una precisión de 2, 4, 8 ... segundos en lugar de 1 segundo) y usando un valor de 32 bits para almacenarlo.

Answer 5

SQLite does not tienen tipos sin firmar. Eso es directamente del autor principal, así como el docs. Además, no tiene anchos de columna fijos para enteros; el ancho real en el disco es un detalle de implementación.

SQLite no tiene fecha o tipo de datos de tiempo. Sin embargo, tiene funciones de fecha que pueden operar en cadenas ISO8601 (TEXT), números de días julianos (REAL) y marcas de tiempo Unix (INTEGER).

Así que si usted decide hacer su campo de tiempo de una marca de tiempo Unix, sabe que puede almacenar hasta a números enteros de 64 bits con signo, pero los valores se almacenan ahora en realidad debe ocupar 32 bits en el disco, incluso si el valor de la fuente es un time_t de 64 bits.