Enteros de época versus columnas de marca de tiempo: por qué la unidad pertenece al esquema

creado_en: 1700000000 o 1700000000000? — la columna que dos servicios escribieron en diferentes unidades durante seis meses

Una columna denominada `created_at` que contiene 1,738,578,000 y 1,738,578,000,000 no se puede interpretar de forma coherente. La clasificación numérica separa a los escritores por escala en lugar de cronología, y la detección automática en cada lector oculta la corrupción en lugar de repararla. El esquema no pudo conservar una unidad requerida.

Antes de la migración, perfile los valores por productor y compare filas representativas con evidencia de eventos independientes. No divida ciegamente todos los valores largos; una columna mixta necesita procedencia o una clasificación cuidadosamente delimitada. ToolAcre ayuda a inspeccionar muestras pero no infiere qué servicio escribió cada fila.

Las magnitudes mixtas también pueden distorsionar los índices y las consultas de retención antes de que alguien abra una fila. Trate el descubrimiento como un incidente de integridad de los datos, no simplemente como un defecto de formato en un cliente.

El caso de las épocas enteras: portabilidad, clasificación, aritmética e independencia de la configuración de zona horaria de la base de datos

Una época entera es compacta para intercambiar y sencilla de comparar cuando el origen, la unidad y el ancho son fijos. Evita el almacenamiento de texto con formato local y admite la aritmética de duración después de la normalización. Esos beneficios provienen de un contrato en torno al número, no de INTEGER por sí solo.

Los costos aparecen cuando ese contrato está ausente: los humanos no pueden leer el valor directamente, un cliente genérico puede redondear números enteros grandes y un tipo de columna no dice nada sobre segundos versus milisegundos. Agregue un sufijo de unidad o una descripción de esquema y valide los escritores en el límite.

Un contrato de números enteros también debe indicar el redondeo para entradas de menos de un segundo. El suelo, el truncamiento o el redondeo pueden asignar eventos de límites a diferentes segundos incluso cuando la escala es correcta.

Las épocas enteras ofrecen un intercambio numérico simple, con compensaciones determinadas por el esquema circundante.

Un tipo temporal nativo de la base de datos puede exponer operaciones de fecha legibles y rechazar algunas entradas no válidas, pero la semántica de rango, zona horaria y la representación del cliente varían según el motor y el tipo. El repositorio de marcas de tiempo no contiene ningún adaptador de base de datos, por lo que no puede clasificar esos productos ni garantizar el "conocimiento" a partir de un nombre de tipo genérico.

Lea la documentación actual del motor elegido y pruebe el controlador. Algunos clientes pueden devolver cadenas, objetos de fecha o valores ajustados por zona. Un tipo nativo reduce ciertas ambigüedades sólo cuando se comprenden el tipo exacto y el comportamiento de la sesión; no es un sustituto universal de un modelo de tiempo de aplicación.

El comportamiento de la marca de tiempo nativa es específico de la base de datos y debe verificarse en ese motor

Un entero estrecho con signo y un entero ancho tienen rangos diferentes, pero el ancho aún no codifica la escala. Un BIGINT puede contener de forma segura muchos milisegundos sin dejar de tener un nombre semántico. Por el contrario, un campo de segundos de 32 bits se acerca a un límite conocido aunque sus valores parezcan normales hoy en día.

Los comentarios reclamados del libro de trabajo son el único registro, lo cual es demasiado absoluto. Los nombres, tipos de dominio, restricciones, esquemas generados y especificaciones API pueden llevar la unidad. Utilice más de una capa ejecutable. Los comentarios humanos ayudan a los revisores, mientras que el código y la validación impiden que un escritor cambie silenciosamente de escala.

El ancho del campo y la unidad son decisiones de esquema independientes

Supongamos que una fila creada durante una implementación conocida de 2025 contiene `1738578060000`. En milisegundos se convierte en `2025-02-03T10:21:00.000Z`; como segundos, está fuera de las expectativas ordinarias y puede exceder el alcance del consumidor. Una fila vecina `1738578060` se asigna al mismo instante que segundos.

Ese par sugiere unidades mixtas pero no prueba qué escritores son responsables. Agrupe por versión del servicio, ruta de ingesta o magnitud, luego verifique varios eventos conocidos. Conservar copias de seguridad y registros de migración. El convertidor es una lente de auditoría, no un motor de reescritura masiva.

Audite varias fechas durante el período afectado. Una coincidencia coincidente puede ser engañosa, mientras que un patrón consistente y específico de un productor respalda una regla de migración controlada.

Ejemplo resuelto: determinar la escala de una columna heredada sospechosa a partir de registros conocidos

Evite la recurrencia nombrando campos sin formato `created_at_s` o `created_at_ms`, analizando en un adaptador y exponiendo un único tipo instantáneo interno. Almacenar instantes UTC; aplique la presentación local solo en los bordes orientados al usuario. Si es preferible un valor API textual, solicite un desplazamiento explícito o Z.

Las pruebas deben enviar valores distinguibles a través de cada límite de serialización. El cero es un mal resultado porque ambas escalas concuerdan. Afirme un instante ISO fijo y realice un viaje de ida y vuelta a través del controlador real. Eso detecta la pérdida de unidades antes de que dos servicios llenen una columna de manera diferente durante meses.

Durante la migración, rechace nuevas escrituras que violen el contrato elegido antes de reparar filas antiguas. De lo contrario, la limpieza acelera una fuente activa que continúa creando datos mixtos.

Lo que esto no cubre: funciones específicas de la base de datos como FROM_UNIXTIME y to_timestamp, que varían según el motor.

Este artículo no prescribe `FROM_UNIXTIME`, `to_timestamp` o funciones equivalentes. Sus unidades de entrada, rangos e interacciones de zona pertenecen a motores y versiones específicos, ninguno de los cuales forma parte de la implementación de ToolAcre. Copiar el nombre de una función en bases de datos puede crear la misma ambigüedad que se analiza.

Utilice la documentación del proveedor y una tabla desechable para demostrar las conversiones antes de una migración. Evite que las transformaciones de aplicaciones y bases de datos apliquen el mismo desplazamiento o factor. Una única conversión de propiedad reconocida es más fácil de probar que una cadena de conversiones implícitas.

Ejecute la función de base de datos contra elementos de límite en la misma configuración de sesión que la producción. Los valores predeterminados de la zona de sesión pueden alterar los resultados textuales incluso cuando la aritmética de época es correcta.

Conclusión: el esquema es donde reside la unidad y cómo el conversor de marcas de tiempo de Unix le ayuda a auditar los datos existentes indicando la unidad que aplicó.

El esquema debe hacer que la representación de una marca de tiempo no sorprenda a ningún escritor ni lector. Los números enteros pueden ser apropiados; Las columnas temporales nativas pueden ser apropiadas. Una escala sin nombre no lo es. Elija un contrato, ejecútelo y trate la conversión como una operación de límites explícita.

Para datos heredados, inspeccione muestras en ambas unidades, correlacionelas con eventos conocidos y registre la incertidumbre. La selección de unidades visibles de ToolAcre respalda esa investigación, pero la decisión final de migración debe provenir de la procedencia y la semántica real de la base de datos.

Una revisión de esquema se completa solo cuando los escritores, lectores, índices y trabajos de retención comparten el mismo modelo. Arreglar el comentario de la columna por sí solo deja intacta la ambigüedad ejecutable.