Un desfase (offset) como +01:00 dice a qué distancia de UTC está un reloj en un momento concreto. Una zona horaria como Europe/Madrid es el conjunto de reglas que decide qué desfase se aplica en cada fecha, pasada y futura. En una línea de log se parecen, pero solo la zona puede responder "¿cuál será el desfase el próximo julio?", y solo la zona sobrevive a que un gobierno cambie de opinión. Si guardas el desfase donde necesitabas la zona, esa información se pierde y no se puede recuperar a partir del número.
¿Cuál es la diferencia entre un desfase y una zona horaria?
Un desfase es una medición. Madrid en enero es +01:00; Madrid en julio es +02:00. La misma ciudad, la misma zona, dos desfases. El nombre de la zona es lo que sabe por qué: contiene el desfase estándar, la regla de cuándo empieza y termina el horario de verano, y la historia de todas las veces que esas reglas fueron distintas.
| Desfase | Zona horaria | |
|---|---|---|
| Ejemplo | -03:00, +05:30 | America/Argentina/Buenos_Aires, Asia/Kolkata |
| Es | un número, válido para un instante | el nombre de un conjunto de reglas |
| Cambia con el horario de verano | sí, cambia el número mismo | no, el nombre se queda y las reglas producen un número nuevo |
| Puede decirte el desfase del mes que viene | no | sí, si las reglas no han cambiado para entonces |
| Lo comparten varios lugares | sí, muchas zonas tienen +01:00 ahora mismo | no, un nombre por región con su propia historia |
Dos lugares pueden compartir un desfase hoy y aun así ser zonas distintas. Sus relojes coinciden esta semana y difieren en primavera, porque uno se mueve y el otro no. El desfase no los distingue. El nombre sí.
¿Por qué no puedes deducir la zona a partir del desfase?
Porque la correspondencia solo va en un sentido. Muchas zonas tienen -03:00 en algún momento; un -03:00 suelto no revela ninguna de ellas. Las abreviaturas son peores: CST se usa para la hora estándar central de Estados Unidos, la hora estándar de China y la hora estándar de Cuba, y nada en las tres letras dice cuál. Trata una abreviatura como decoración para un lector humano, no como dato.
La dirección contraria funciona, pero solo para una fecha. Dale un nombre de zona y un instante y obtienes exactamente un desfase. Dale un desfase y no obtienes nada sobre ningún otro instante.
¿Qué sabe una zona que un desfase no sabe?
Todo lo que una legislatura haya decidido alguna vez sobre los relojes. Las reglas las escriben los gobiernos, y los gobiernos las cambian, a veces con semanas de aviso. Estados Unidos alargó el horario de verano a partir de 2007. México lo abolió para la mayor parte del país en 2022. Argentina lleva años en -03:00 todo el año, mientras que Europe/Madrid sigue oscilando entre +01:00 y +02:00. Algunas zonas quedan fuera de la hora en punto: Asia/Kolkata es +05:30 y Nepal es +05:45.
El software no lleva estas reglas escritas en el código. Las lee de la base de datos de zonas horarias de IANA, que se actualiza varias veces al año justamente porque las reglas no dejan de moverse. Un teléfono viejo o un servidor que nunca se parchó puede estar equivocado sobre una zona cuya regla cambió después de su última actualización, y ningún código tuyo lo arregla salvo actualizando los datos.
Por eso mismo el desfase que obtienes para una fecha lejana en el futuro es un pronóstico, no un hecho. Toma "las 9:00 en Madrid el 15 de julio de 2031". Las reglas de hoy dicen +02:00. Si cambian antes, esa misma hora de reloj pasa a ser un instante distinto.
¿Cuándo un desfase pierde información que necesitas?
Siempre que la pregunta sea sobre una hora que todavía no ha ocurrido, o sobre una hora de reloj de pared y no de un log. Una "hora" puede significar dos cosas distintas, y cada una pide un almacenamiento distinto.
- Algo que ya ocurrió (un pago, un inicio de sesión, una línea de log). Es un instante. Guárdalo como un timestamp UTC, o como una cadena ISO 8601 con desfase. Aquí el desfase está bien, porque el momento es fijo y nadie te va a pedir recalcularlo.
- Algo que una persona programó (una reunión a las 09:00, un vuelo, una tienda que abre a las 10:00). Es una hora de reloj en un lugar. Guarda la fecha y la hora locales más el nombre de la zona, y calcula el instante cuando lo necesites.
Si guardas el segundo tipo como un instante UTC, tendrás razón hasta que cambien las reglas. Digamos que reservas una reunión el martes a las 09:00 en Madrid y la guardas como las 07:00 UTC, porque eso te dio el desfase en verano. Si la reunión es en noviembre, cuando Madrid está en +01:00, el calendario ahora la muestra a las 08:00 para todos en Madrid. Nada estaba mal en el momento de guardar. La zona lo habría sabido; el desfase no podía.
Guardar solo el desfase falla igual con los eventos recurrentes. "Cada lunes a las 09:00, +01:00" es correcto hasta que los relojes se adelantan, y entonces se dispara una hora fuera de la hora local durante medio año.
¿Qué falla dos veces al año y qué se salta el reloj local?
Cuando los relojes se adelantan, un tramo de hora local no existe. Cuando se atrasan, un tramo ocurre dos veces. En una zona que se mueve a las 02:00 en primavera, las 02:30 no aparecen ese día en el reloj de pared. En otoño, la 01:30 aparece dos veces, con una hora de diferencia, con dos desfases distintos.
Así que una hora local sin desfase puede ser inválida, o puede nombrar dos instantes. Por eso "1 de noviembre de 2026, 01:30, Nueva York" no basta para identificar un momento en los días en que cambian los relojes, y por eso las bases de datos que aceptan una hora local con un nombre de zona necesitan una regla para esas horas. También es por lo que una duración de "24 horas" y "un día" no son lo mismo en esas dos fechas, la misma trampa que hace que contar los días entre dos fechas dependa de qué cuentes.
¿Qué puede mostrar el conversor de timestamps y qué no?
Pega un timestamp en el conversor de timestamps Unix y la línea "ISO 8601 (desfase local)" te da el desfase que tenía la zona de tu dispositivo en ese momento, junto a la línea UTC. Prueba con uno de enero y otro de julio y el desfase local cambia mientras la zona no. Esa es la diferencia en una sola pantalla, y nada sale de la página.
Lo que no hace importa aquí. Solo tiene dos zonas, la tuya y UTC, sin selector, así que no puede decirte qué es un momento en Madrid a menos que estés en Madrid. Muestra el nombre de la zona de tu dispositivo pero no te deja introducir uno. Y en la dirección de fecha a timestamp, te pide una hora local sin desfase y luego usa tu navegador para resolverla. Para las horas saltadas y repetidas de arriba, no te avisa de que la hora era inválida o ambigua; el navegador elige una lectura sin decir nada. Comprobar un día de cambio de hora corre por tu cuenta.
El mismo límite se aplica a las fechas antiguas. Las horas locales anteriores a 1970 dependen de datos históricos de zonas que tu navegador quizá no tenga completos, así que una hora local convertida anterior a 1970 puede estar desviada. La línea UTC no se ve afectada.
¿Qué debes guardar?
- Para un evento que ocurrió: un timestamp UTC. Si quieres también la vista local, guarda el nombre de la zona en la que ocurrió como un campo aparte, no metido dentro de la hora.
- Para un evento que una persona programó: la fecha local, la hora local y el nombre de la zona, como tres campos. Calcula el instante en el último momento posible.
- Para una fecha sin hora (un cumpleaños, la fecha de una factura): un simple
YYYY-MM-DDy ninguna zona. Un timestamp Unix es el tipo equivocado para eso. - Nunca la abreviatura de tres letras como dato, y nunca un desfase como sustituto de una zona.
Guarda el desfase además del nombre de la zona si quieres un registro de cuál era el desfase en ese momento. Es útil para las pistas de auditoría. No reemplaza al nombre.
Para ver la diferencia por ti mismo, pon un timestamp de enero y uno de julio en el conversor de timestamps Unix y compara el desfase local de cada uno. Recuerda que solo muestra la zona de tu propio dispositivo y UTC, así que no sustituye a un selector de zonas de verdad.
Si quieres la otra mitad de la historia, qué es un timestamp Unix explica por qué un instante no necesita ninguna zona, que es justamente la razón por la que una hora de reloj programada necesita una guardada al lado.
Preguntas frecuentes
¿Cuál es la diferencia entre una zona horaria y un desfase UTC?
Un desfase UTC, como +01:00, es un único número que dice a qué distancia de UTC está un reloj en un momento concreto. Una zona horaria, como Europe/Madrid, es un conjunto de reglas con nombre que decide qué desfase se aplica en cada fecha, incluido el horario de verano y los cambios pasados. Una misma zona produce desfases distintos a lo largo del año.
¿Debo guardar una zona horaria o un desfase en mi base de datos?
Depende de lo que signifique la hora. Para algo que ya ocurrió, guarda un timestamp UTC; el desfase es opcional. Para algo que una persona programó en un lugar, como una reunión o un vuelo, guarda la fecha y hora locales junto con el nombre de la zona, porque el desfase puede cambiar antes de que ocurra el evento.
¿Puedo saber la zona horaria a partir de un desfase UTC?
No. Muchas zonas distintas comparten el mismo desfase en un momento dado, y pueden diferir en otras épocas del año. Un desfase solo reduce la respuesta a una lista de candidatas. Necesitas el nombre de la zona, o una ubicación, para conocer las reglas.
¿Por qué cambian las reglas de las zonas horarias?
Las fijan los gobiernos, y los gobiernos las cambian por motivos de energía, política o economía, a veces con poco aviso. El software lee las reglas de la base de datos de zonas horarias de IANA, que se actualiza varias veces al año. Un sistema que no aplicó la última actualización puede estar equivocado sobre una zona cuya regla cambió hace poco.
¿EST o CST son una zona horaria?
Son abreviaturas, no identificadores. CST por sí sola puede significar hora estándar central de Estados Unidos, hora estándar de China u hora estándar de Cuba, y las letras no dicen cuál. Para datos usa un nombre IANA como America/Chicago, y trata la abreviatura como texto para un lector humano y nada más.
Última actualización 29 de septiembre de 2026
