Los tipos de fecha y hora en bases de datos sirven para diferentes propósitos. DATE almacena solo una fecha (2026-05-15), TIME almacena solo una hora (14:30:00), TIMESTAMP combina ambos (2026-05-15 14:30:00). El TIMESTAMPTZ de PostgreSQL (TIMESTAMP WITH TIME ZONE) es el tipo especial que convierte las entradas a UTC para almacenarlas y las reconvierte a la zona de la sesión al leerlas.
La pregunta de diseño más importante es si cada valor de fecha y hora necesita semántica de zona horaria. Las marcas de tiempo de eventos (registros, transacciones) representan instantes absolutos y deben ser TIMESTAMPTZ. Los cumpleaños y aniversarios son fechas independientes de la zona y DATE es suficiente. Los horarios comerciales como «9:00-18:00» usan TIME sin zona, pero la zona relevante debe rastrearse en otro lugar. Elige según el significado, no por costumbre.
Para reservas de hoteles y restaurantes, la hora de la reserva es significativa en la hora local del establecimiento. Almacenar «7 PM en un restaurante de Tokio» como 10:00 UTC funciona bien en Japón, que no tiene horario de verano. Pero para un restaurante en Nueva York, el desfase UTC varía estacionalmente, y almacenar como UTC conlleva el riesgo de reinterpretación posterior cuando las reglas de horario de verano se apliquen de forma diferente a la esperada.
La solución es almacenar TIMESTAMPTZ junto con el nombre de zona IANA del establecimiento en una columna separada. Al mostrar los datos, se convierte el instante UTC usando la zona guardada, produciendo siempre la hora local correcta. Un patrón alternativo almacena la hora local como TIMESTAMP (sin zona) junto con el nombre de zona, tratando ambos como necesarios para interpretar el valor correctamente.
Almacenar eventos futuros (una conferencia el próximo año, una reunión recurrente dentro de varios meses) tiene trampas únicas. Si el país del evento cambia su política de horario de verano, un tiempo almacenado en UTC ya no corresponde a la hora local prevista. Almacenar «15 de marzo de 2027 a las 10:00 hora de Nueva York» como 15:00 UTC, y luego que EE. UU. aboliera el horario de verano, desplazaría el UTC correcto a 14:00.
El remedio es almacenar los eventos futuros como (hora local, nombre de zona) y convertir a UTC bajo demanda en el momento de mostrar o enviar recordatorios. A medida que la base de datos IANA se actualiza, las conversiones siguen automáticamente las nuevas reglas. Los eventos pasados que ya han ocurrido pueden almacenarse de forma segura en UTC porque ningún cambio de reglas puede alterar retroactivamente lo que sucedió.
Las marcas de tiempo de los registros de auditoría pueden servir como evidencia legal del orden de los eventos, por lo que requieren el diseño más estricto. Usa TIMESTAMPTZ generado por la función NOW() del servidor de base de datos en lugar del reloj del servidor de aplicación. Esto previene la manipulación por parte de clientes que controlan sus propios relojes, lo cual sería un riesgo de credibilidad.
En sistemas distribuidos, múltiples nodos de base de datos pueden tener relojes ligeramente diferentes. Cuando se requiere un orden estricto, complementa las marcas de tiempo con un número de secuencia monótonamente creciente, o adopta el enfoque de Reloj Lógico Híbrido (HLC). Regulaciones financieras como MiFID II exigen marcas de tiempo UTC trazables con precisión de microsegundos, por lo que la monitorización de la sincronización NTP/PTP se convierte en parte del diseño operativo en lugar de una reflexión posterior.
Migrar sistemas construidos sin conciencia de zona horaria comienza por identificar «¿qué zona asumen implícitamente estos datos?». Los sistemas construidos en Japón a menudo asumen JST; los sistemas en AWS a menudo asumen UTC; los orígenes mixtos son comunes. Documenta la zona asumida para cada columna antes de cambiar nada.
El procedimiento seguro es añadir una nueva columna TIMESTAMPTZ, convertir y copiar los datos existentes con el desfase apropiado, cambiar la aplicación para leer de la nueva columna, verificar y finalmente eliminar la columna antigua. Presta especial atención a los datos de las transiciones de horario de verano durante la conversión masiva, particularmente durante las ventanas de solapamiento del retroceso otoñal donde existen dos interpretaciones para la misma hora de reloj.
¿Te resultó útil este artículo?
Los errores de zona horaria en MySQL casi siempre se deben a un malentendido de tres capas: los valores predeterminados del servidor, la configuración de sesión y los tipos de columna. Este artículo explica por qué TIMESTAMP y DATETIME se comportan de forma diferente, cómo interactúa la variable time_zone con las conexiones y cómo configurar correctamente los controladores JDBC.
Las tareas cron configuradas en hora local se ejecutan dos veces o se saltan silenciosamente durante las transiciones de horario de verano. Este artículo repasa los modos de fallo, el caso a favor de ejecutar programaciones en UTC, el campo timeZone de Kubernetes CronJob y cómo los planificadores en la nube gestionan el mismo problema.
Los nómadas digitales enfrentan una versión más aguda del desafío horario: su ubicación cambia constantemente, así que el desfase con los clientes varía semana a semana. Este artículo cubre la estrategia de zona ancla, los cambios graduales de horario, las herramientas y los límites que hacen sostenible el trabajo nómada.