En SQL existe un amplio conjunto de funciones para trabajar con fechas e intervalos: DATEDIFF, DATEADD (T-SQL), manejo del tipo INTERVAL (PostgreSQL), funcionalidad para convertir tiempos a diferentes zonas (AT TIME ZONE). Para un correcto manejo de las fechas, es clave usar tipos de datos que consideren la zona horaria (TIMESTAMP WITH TIME ZONE, timestamptz), y no simplemente DATE o DATETIME, especialmente para servicios globales.
En diferentes SGBD, la sintaxis y las características de funcionamiento varían:
DATEDIFF, DATEADD, FORMAT, pero no hay un INTERVAL completo. Las zonas horarias se manejan de forma explícita.Los errores a menudo surgen por la inconsistencia en almacenar en UTC/hora local y la mezcla de operaciones que no consideran la diferencia.
SELECT EXTRACT(EPOCH FROM (event_end AT TIME ZONE 'UTC' - event_start AT TIME ZONE 'UTC')) / 3600 AS hours FROM events
¿Puede la diferencia de fechas en DATEDIFF dar un número negativo, y qué significa su orden de aparición?
Respuesta: Sí, DATEDIFF (DATEDIFF(day, d1, d2)) devuelve un número negativo si d2 < d1. Es importante no confundir el orden de los parámetros: primero va la unidad de medida, luego la fecha inicial y después la fecha final.
Ejemplo:
SELECT DATEDIFF(day, '2024-05-01', '2024-04-25') -- devolverá -6
Historia
En un proyecto con usuarios globales, los informes se construían según la hora local de los servidores en cada región. Resultado: agregados desincronizados por fechas y aparición de "huecos" en el límite de días para usuarios de otros husos horarios. Se corrigió convirtiendo todos los datos temporales a UTC y recalculando solo para la visualización.
Historia
Al calcular la duración de una suscripción a través de DATEDIFF, se confundió el orden de las fechas. Como resultado, algunos usuarios fueron erróneamente considerados "superusuarios" con antigüedad negativa. Se corrigió introduciendo una verificación del orden de las fechas.
Historia
Un desarrollador almacenó DATETIME sin considerar la zona horaria, al migrar a PostgreSQL los valores resultaron interpretados como UTC, aunque originalmente estaban en GMT+3, lo que llevó a un desfase de eventos en los informes de 3 horas atrás. Conclusión: ¡siempre almacenar y convertir fechas considerando la zona!