Reglas prácticas para evitar errores por horario de verano: guarda marcas de tiempo limpias en UTC, muestra la hora local correcta y crea informes que los usuarios puedan verificar y confiar.
Los fallos de tiempo aparecen en productos normales porque la gente no vive en UTC. Vive en hora local, y la hora local puede adelantar, atrasar o cambiar reglas con los años. Dos usuarios pueden mirar el mismo instante y ver relojes distintos. Peor aún: la misma hora del reloj local puede corresponder a dos momentos reales diferentes.
Los errores por horario de verano (DST) suelen aparecer solo dos veces al año, así que pasan desapercibidos. Todo parece bien en desarrollo, y luego un cliente real reserva una cita, registra una hoja de horas o revisa un informe en el fin de semana del cambio y algo no cuadra.
Los equipos suelen notar primero unos patrones: una “hora faltante” donde elementos programados desaparecen o se desplazan, una hora duplicada donde registros o alertas parecen repetidos, y totales diarios que derivan porque un “día” duró 23 o 25 horas.
Esto no es solo un problema de desarrolladores. Soporte recibe tickets como “su app cambió mi reunión”. Finanzas ve ingresos diarios que no coinciden. Operaciones se pregunta por qué jobs nocturnos se ejecutaron dos veces o se saltaron. Incluso los filtros de “creado hoy” pueden discrepar entre usuarios de distintas regiones.
La meta es aburrida y fiable: almacenar el tiempo de forma que nunca pierda significado, mostrar la hora local como la espera la gente, y construir informes que sean veraces incluso en los días raros. Cuando haces eso, todas las áreas del negocio pueden confiar en los números.
Tanto si construyes con código propio como con una plataforma como AppMaster, las reglas son las mismas. Quieres marcas de tiempo que conserven el momento original, más suficiente contexto (como la zona horaria del usuario) para explicar cómo se veía ese momento en su reloj.
La mayoría de los errores de DST ocurren porque confundimos “un instante en el tiempo” con “cómo lo muestra un reloj”. Mantén esas ideas separadas y las reglas se simplifican mucho.
Algunos términos, en lenguaje llano:
Un desfase no es lo mismo que una zona horaria. -05:00 solo te dice la diferencia respecto a UTC en un instante. No te dice si ese lugar pasa a -04:00 en verano, o si las leyes cambian el año que viene. Un nombre de zona sí lo hace, porque contiene reglas e historial.
DST cambia el desfase, no la marca de tiempo subyacente. El evento sigue ocurriendo en el mismo instante; solo cambia la etiqueta del reloj local.
Dos situaciones causan la mayor parte de la confusión:
Si un ticket de soporte se crea a “1:30 AM” durante la repetición de otoño, necesitas la zona horaria y el instante exacto (marca UTC) para ordenar los eventos correctamente.
La mayoría de los errores por DST empiezan como un problema de datos, no de formato. Si el valor almacenado es ambiguo, cada pantalla e informe deberá adivinar, y esas conjeturas no coincidirán.
Si algo ocurrió en un momento específico (un pago capturado, una respuesta a un ticket, un turno iniciado), guarda la marca de tiempo en UTC. UTC no adelanta ni atrasa, así que se mantiene estable frente a cambios de DST.
Ejemplo: Un agente de soporte en Nueva York responde a las 9:15 AM hora local el día del cambio de reloj. Guardar el momento en UTC mantiene esa respuesta en el orden correcto cuando alguien en Londres revisa el hilo más tarde.
Cuando necesites mostrar la hora de forma humana, necesitas saber la zona horaria del usuario o la ubicación. Guárdala como un ID de zona IANA como America/New_York o Europe/London, no como una etiqueta vaga como “EST”. Las abreviaturas pueden significar cosas distintas, y los desfases por sí solos no capturan las reglas de DST.
Un patrón simple es: tiempo del evento en UTC, más un ID de zona separado adjunto al usuario, oficina, tienda o dispositivo.
Algunos valores no son instantes en el tiempo. Cumpleaños, “renueva el día 5” y “fecha de vencimiento” suelen guardarse como un campo solo fecha. Si los guardas como timestamp, las conversiones de zona pueden moverlos al día anterior o siguiente.
Evita guardar valores como “2026-03-08 02:30” o “9:00 AM” sin una zona horaria. Esa hora puede ser ambigua (ocurre dos veces) o imposible (se salta) durante las transiciones de DST.
Si debes aceptar entrada local, guarda tanto el valor local como el ID de zona, y convierte a UTC para el momento real del evento.
Muchos errores de DST suceden porque un tipo de registro se trata como otro. Un registro de auditoría, una reunión de calendario y un cierre de nómina parecen “una fecha y hora”, pero necesitan datos distintos para mantenerse precisos.
Para eventos pasados (cosas que ya sucedieron): guarda un instante exacto, normalmente una marca UTC. Si alguna vez necesitas explicar cómo lo vio el usuario, guarda también la zona horaria del usuario en el momento del evento (un ID IANA como America/New_York, no solo “EST”). Eso te permite reconstruir lo que se mostró en pantalla aunque el usuario cambie después su zona en el perfil.
Para programación (cosas que deben ocurrir a una hora del reloj local): guarda la fecha y hora local previstas más el ID de zona. No lo conviertas a UTC y descartes el original. “10 de marzo a las 09:00 en Europe/Berlin” es la intención. UTC es un valor derivado que puede cambiar si las reglas cambian.
Los cambios son normales: la gente viaja, las oficinas se mudan, las empresas actualizan políticas. Para registros históricos, no reescribas tiempos pasados cuando un usuario actualice su zona horaria del perfil. Para programaciones futuras, decide si la programación sigue al usuario (adecuado si viaja) o sigue a una ubicación fija (adecuado para oficinas), y almacena esa zona de ubicación.
Los datos heredados con solo timestamps locales son complicados. Si conoces la zona origen, adjúntala y trata la hora antigua como local. Si no la conoces, márcala como “flotante” y sé transparente en los informes (por ejemplo, muestra el valor almacenado sin conversión). También ayuda modelar estos como campos separados para que pantallas e informes no los mezclen accidentalmente.
Para evitar errores por DST, elige un sistema de registro no ambiguo para el tiempo y convierte solo cuando lo muestres a las personas.
Escribe la regla para tu equipo: todas las marcas de tiempo en la base de datos son UTC. Ponlo en la documentación y en comentarios de código cerca del manejo de fechas. Es una decisión que se deshace accidentalmente con facilidad.
Un patrón práctico de almacenamiento se ve así:
created_at_utc).occurred_at_utc) y un tz_id cuando el contexto local importe (usa un ID IANA como America/New_York, no un desfase fijo).tz_id, luego convierte a UTC una sola vez en el borde (API o envío de formulario). No conviertas varias veces en diferentes capas.tz_id y el UTC calculado). Eso te da una pista de auditoría cuando los usuarios disputen una hora.Ejemplo: un usuario programa “5 de noviembre, 9:00 AM” en America/Los_Angeles. Guardas occurred_at_utc = 2026-11-05T17:00:00Z y tz_id = America/Los_Angeles. Incluso si las reglas de DST cambian después, aún puedes explicar qué quisieron decir y qué almacenaste.
Si modelas esto en PostgreSQL (incluyendo mediante herramientas visuales), haz los tipos de columna explícitos y coherentes, y obliga a que la app escriba UTC cada vez.
La mayoría de los errores de DST aparecen en la UI, no en la base de datos. La gente lee lo que muestras, lo copia en mensajes y planifica según ello. Si la pantalla es confusa, los usuarios asumirán lo incorrecto.
Cuando el tiempo importa (reservas, tickets, citas, ventanas de entrega), muéstralo como en un recibo: completo, específico y etiquetado.
Haz que la presentación sea predecible:
Los casos límite de DST necesitan comportamientos explícitos. Si dejas que los usuarios tecleen cualquier hora, acabarás aceptando una hora que no existe o que se repite.
Ejemplo: Un agente en Berlín programa una llamada con un cliente en Nueva York para “3 nov, 1:30 AM”. Durante la repetición de otoño, esa hora ocurre dos veces en Nueva York. Si la UI muestra “3 nov, 1:30 AM (UTC-4)”, la confusión desaparece.
Los informes rompen la confianza cuando los mismos datos dan totales distintos según dónde mire el usuario. Para evitar errores por DST, decide qué significa realmente “día” en cada informe y cúmplelo.
Primero, elige el significado de “día” para cada informe. Un equipo de soporte suele pensar en el día local del cliente. Finanzas necesita a menudo la zona horaria legal de la cuenta. Algunos informes técnicos son más seguros en días UTC.
Agrupar por día local cambia los totales alrededor de DST. En el día de adelanto, se salta una hora local. En el día de retraso, una hora se repite. Si agrupas eventos por “fecha local” sin una regla clara, una hora ocupada puede parecer faltante, duplicada o movida al día equivocado.
Una regla práctica: todo informe tiene una zona horaria de reporte y se muestra en el encabezado (por ejemplo, “Todas las fechas en America/New_York”). Eso hace las cuentas predecibles y da a soporte algo claro que señalar.
Para equipos multirregión, está bien permitir que la gente cambie la zona del informe, pero trátalo como una vista diferente de la misma verdad. Dos espectadores pueden ver buckets diarios distintos cerca de medianoche y en transiciones de DST. Eso es normal si el informe indica la zona seleccionada.
Algunas decisiones que previenen sorpresas:
Las duraciones requieren cuidado especial. Un “turno de 2 horas” que cruza el cambio de otoño son 3 horas en el reloj de pared pero siguen siendo 2 horas transcurridas si la persona trabajó 2 horas. Decide qué significado esperan tus usuarios y aplica redondeos consistentes (por ejemplo, redondea después de sumar, no por fila).
Los errores de DST no son “matemáticas difíciles”. Provienen de pequeñas suposiciones que se acumulan con el tiempo.
Un fallo clásico es guardar una hora local pero etiquetarla como UTC. Todo parece bien hasta que alguien en otra zona abre el registro y este cambia silenciosamente. La regla más segura es simple: guarda un instante (UTC) más el contexto correcto (zona del usuario o ubicación) cuando el registro necesita un significado local.
Otra fuente frecuente de errores es usar desfases fijos como -05:00. Los desfases no conocen cambios de DST ni reglas históricas. Usa IDs reales de zona IANA (como America/New_York) para que el sistema aplique la regla correcta según la fecha.
Unos hábitos previenen muchas sorpresas de “turno doble”:
También vigila conversiones ocultas. Un patrón común: parsear la hora local del usuario a UTC, luego una librería de UI asume que el valor es local y vuelve a convertir. El resultado es un salto de una hora que solo aparece para algunos usuarios y algunas fechas.
Finalmente, no uses la zona horaria del dispositivo del cliente para facturación o cumplimiento. El teléfono de un viajero puede cambiar de zona en medio del viaje. En su lugar, basa esos informes en una regla de negocio explícita, como la zona de la cuenta del cliente o la ubicación del sitio.
La mayoría de errores de tiempo aparecen solo unos días al año, por eso se escapan del QA. La solución es probar los momentos correctos y hacer esas pruebas repetibles.
Elige una zona que observe DST (por ejemplo, America/New_York o Europe/Berlin) y escribe pruebas para los dos días de transición. Luego elige una zona que nunca usa DST (por ejemplo, Asia/Singapore o Africa/Nairobi) para ver la diferencia con claridad.
Imagina que un equipo de soporte programa un seguimiento a “01:30” en la noche de retraso de otoño. Si la UI solo guarda la hora local mostrada, no puedes saber qué “01:30” quisieron decir. Una buena prueba crea ambos timestamps UTC que localmente se muestran como 01:30 y confirma que la app los mantiene distintos.
Estas pruebas muestran rápido si tu sistema guarda los datos correctos (instante UTC, ID de zona y a veces la hora local original) y si los informes se mantienen honestos cuando cambian los relojes.
Los errores por horario de verano se cuelan porque la app parece correcta la mayor parte del tiempo. Usa esta lista antes de lanzar cualquier cosa que muestre tiempo, filtre por fecha o exporte informes.
created_at, paid_at, message_sent_at). Guarda el ID de zona IANA cuando necesites contexto.Un chequeo de realidad: si un manager de soporte en Nueva York exporta “Tickets creados el domingo” y un compañero en Londres abre el archivo, ambos deberían poder decir qué zona horaria representan los timestamps sin adivinar.
Un cliente en Nueva York crea un ticket de soporte la semana en que EE. UU. ya cambió al horario de verano pero Reino Unido aún no. Tu equipo de soporte está en Londres.
El 12 de marzo, el cliente envía el ticket a las 09:30 hora local en Nueva York. Ese instante es 13:30 UTC, porque Nueva York ahora está en UTC-4. Un agente en Londres responde a las 14:10 hora de Londres, que es 14:10 UTC (Londres aún está en UTC+0 esa semana). La respuesta llegó 40 minutos después de creado el ticket.
Así es como esto falla si solo guardas hora local sin ID de zona:
El modelo más seguro mantiene UI e informes consistentes. Guarda el tiempo del evento como timestamp UTC y el ID IANA relevante (por ejemplo, America/New_York para el cliente, Europe/London para el agente). En la UI, muestra el mismo instante UTC en la zona del espectador usando las reglas guardadas para esa fecha.
Para el informe semanal, elige una regla clara como “agrupar por día local del cliente”. Calcula los límites del día en America/New_York (medianoche a medianoche), convierte esos límites a UTC y cuenta los tickets dentro de ellos. Los números se mantienen estables incluso durante semanas con DST.
Si tu producto ha sufrido errores por DST, la forma más rápida de salir es escribir unas reglas y aplicarlas por todas partes. “Mayormente consistente” es donde viven los problemas de tiempo.
Mantén las reglas cortas y específicas:
Despliega los cambios de forma de bajo riesgo. Arregla primero los registros nuevos para que el problema deje de crecer. Luego migra datos históricos por lotes. Durante la migración, conserva tanto el valor original (si lo tienes) como el valor normalizado el tiempo suficiente para detectar diferencias en informes.
Si usas AppMaster (appmaster.io), un beneficio práctico es centralizar estas reglas en tu modelo de datos y lógica compartida: guarda timestamps en UTC de forma consistente, mantén IDs IANA junto a registros que necesiten significado local y aplica conversiones en los límites de entrada y visualización.
Un paso práctico siguiente es construir un informe seguro en zonas horarias (por ejemplo, “tickets resueltos por día”) y validarlo con los casos de prueba arriba. Si se mantiene correcto a través de una semana con cambio de DST en dos zonas distintas, estás en buen camino.
Why do DST bugs happen even when the code looks correct?El horario de verano cambia el desfase de la hora local, no el instante real en que ocurrió un evento. Si tratas una lectura del reloj local como si fuera un instante absoluto, verás horas “faltantes” en primavera y horas “duplicadas” en otoño.
What’s the safest way to store timestamps in a database?Guarda los eventos reales como un instante absoluto en UTC, así el valor no cambia cuando los desfases varían. Convierte a la hora local del espectador solo al mostrarla, usando un nombre de zona horaria real.
Why can’t I store just a UTC offset instead of a time zone name?Un desfase como -05:00 solo describe la diferencia respecto a UTC en un momento concreto y no incluye reglas de DST ni el historial. Una zona IANA como America/New_York lleva el conjunto de reglas completo, así las conversiones son correctas para distintas fechas.
When should I store a value as a date instead of a timestamp?Guarda como fechas los valores que no son instantes reales: cumpleaños, fechas de renovación, vencimientos de facturas, etc. Si los guardas como timestamps, las conversiones entre zonas pueden moverlos al día anterior o siguiente.
How should my app handle times that are skipped or repeated during DST switches?La “primavera” crea horas locales que no existen: bloquea selecciones inválidas y ofrece la siguiente hora válida. La “vuelta al horario” duplica una hora: la interfaz debe permitir elegir qué instancia se quiere, mostrando el desfase para aclararlo.
Should I convert scheduled meetings to UTC when saving them?Para programaciones, guarda la fecha y hora local prevista junto con el ID de zona; esa es la intención del usuario. Puedes guardar un instante UTC derivado para la ejecución, pero no descartes la intención local original, porque podrías perder su significado si las reglas cambian.
How do I stop reports from showing different daily totals for different users?Elige una zona de reporte por informe y muéstrala claramente, así todos sabrán qué significa “día”. Agrupar por día local puede producir días de 23 o 25 horas cerca de DST, y eso está bien mientras el informe indique la zona elegida y la aplique de forma consistente.
What’s the most common mistake that causes the “one-hour shift” bug?La regla práctica es convertir solo en los puntos límites: parsear la entrada una vez, guardar una vez y formatear una vez para mostrar. Las doble-conversiones suelen ocurrir cuando una capa interpreta un timestamp como local y otra como UTC, provocando desplazamientos de una hora que solo aparecen en ciertas fechas.
How should I calculate durations across DST changes?Guarda el tiempo transcurrido en segundos (u otra unidad absoluta) y suma esos valores, luego formatea para mostrar. Decide si te refieres a tiempo transcurrido o a tiempo de reloj antes de implementar nóminas, SLAs o duraciones de turnos, porque las noches con DST pueden hacer que las horas de reloj parezcan más largas o más cortas.
What tests catch most DST bugs before customers do?Prueba ambos días de transición de DST en al menos una zona que observe DST y compáralos con una zona sin DST para detectar suposiciones erróneas. Incluye casos de hora faltante, hora repetida, eventos cerca de medianoche y agrupaciones de informes, porque ahí se suelen ocultar los errores.
21 ene 2026
8 min
20 ene 20268 min
20 ene 20268 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
