Arreglar la hora en Linux: zona horaria, NTP y arranque con Windows

Si el reloj de Linux vuelve a estar mal después de reiniciar, ponerlo a mano puede ocultar el problema durante un rato, pero no explica qué está pasando. Una zona horaria incorrecta, un servicio de sincronización que no funciona y un desacuerdo con Windows sobre el reloj del equipo requieren soluciones distintas.

Vamos a comprobar cada caso en un sistema con systemd, como Ubuntu o Linux Mint. Si estamos administrando un servidor, no cambiamos la hora por probar. Puede afectar a registros, certificados y tareas programadas. Primero identificamos el fallo y después aplicamos sólo el ajuste necesario.

Comprobar el reloj antes de cambiar nada

Abrimos una terminal y ejecutamos:

timedatectl status

Nos fijamos en la hora local, la zona horaria, la sincronización del sistema y si el RTC está en hora local. El RTC es el reloj del hardware, no la zona horaria con la que queremos ver la hora en el escritorio. systemd gestiona estos ajustes por separado mediante systemd-timedated.

La captura muestra una versión antigua de timedatectl. En versiones actuales cambian algunos nombres, por ejemplo NTP service y System clock synchronized.

Si vemos una diferencia exacta de una o dos horas, miramos primero la zona horaria y si el fallo aparece al alternar con Windows. Si el reloj se va retrasando minutos, o arranca en una fecha totalmente incorrecta, la investigación es distinta. No todos los desfases son un problema de arranque dual.

Corregir una zona horaria equivocada

Para consultar las zonas disponibles:

timedatectl list-timezones

Si corresponde a nuestra ubicación, podemos seleccionar Madrid:

sudo timedatectl set-timezone Europe/Madrid

Madrid es un ejemplo, no el valor que todos debemos copiar. Elegimos nuestra zona de la lista y volvemos a consultar el estado. Una zona geográfica permite aplicar sus reglas de horario de verano, en vez de intentar corregir el reloj sumando una hora a mano.

También puede ser normal que un servidor esté en UTC aunque nosotros estemos en España. En ese caso, que no muestre la misma hora local que nuestro portátil no demuestra que esté desajustado.

Comprobar qué servicio sincroniza la hora

No todos los Linux actuales utilizan el mismo programa. Ubuntu pasó a usar Chrony como servicio predeterminado desde 25.10. Otras instalaciones siguen usando systemd-timesyncd. La documentación de Ubuntu explica esa diferencia, así que no debemos instalar otro servicio sólo porque una guía antigua mencione timesyncd.

Podemos consultar ambos sin iniciar ni detener ninguno:

systemctl status chrony.service --no-pager
systemctl status systemd-timesyncd.service --no-pager

Que una de las unidades no exista es posible y no significa que haya que instalarla. Nos interesa identificar la que ya mantiene el reloj. El nombre del servicio puede variar en otras distribuciones.

En una instalación de escritorio donde la sincronización está desactivada y el sistema reconoce un proveedor NTP, podemos activarla con:

sudo timedatectl set-ntp true

Este ajuste solicita activar un servicio de sincronización disponible, no instala uno nuevo. Si devuelve que NTP no está soportado, revisamos qué proveedor tiene instalado y configurado nuestra distribución. No encadenamos instalaciones y reinicios de servicios al azar.

Activado no siempre significa sincronizado

Con systemd-timesyncd, podemos mirar el estado de la sincronización:

timedatectl timesync-status

Esta consulta es específica de timesyncd. Que falle mientras usamos Chrony no demuestra que el reloj esté mal. El manual de systemd-timesyncd describe su funcionamiento y las consultas disponibles.

Si usamos Chrony, consultamos su seguimiento y sus fuentes:

chronyc tracking
chronyc sources

Buscamos una referencia seleccionada y un estado de sincronización normal. La guía de Chrony en Ubuntu explica cómo interpretar sus fuentes. No basta con que el proceso esté ejecutándose, tiene que poder obtener una referencia de tiempo.

Después de recuperar la conexión, damos un margen al servicio y volvemos a consultar el estado. Si sigue sin sincronizar, revisamos sus mensajes y la conectividad con las fuentes configuradas. No hace falta quitar el cortafuegos ni desactivar la validación de certificados para intentar que desaparezca el error.

La hora cambia al arrancar Windows o Linux

En un arranque dual, ambos sistemas comparten el reloj del hardware. Si uno interpreta su valor como UTC y el otro como hora local, pueden aparecer saltos al cambiar de sistema. El manual de hwclock explica por qué distinguir el reloj del sistema, el RTC y la zona horaria.

La solución consiste en que ambos interpreten el RTC de la misma forma. Usar UTC es lo preferible en Linux. Tener el RTC en UTC no obliga a ver UTC en el escritorio, que seguirá mostrando nuestra zona horaria.

Si mantenemos Windows configurado para interpretar el RTC como hora local y decidimos adaptar Linux, primero comprobamos que la hora del sistema ya sea correcta. Después, sólo para ese caso:

sudo timedatectl set-local-rtc 1

No es una recomendación para todos los equipos. El manual de timedatectl advierte de las limitaciones de mantener el RTC en hora local, especialmente con cambios de zona y horario de verano. Este comando también ajusta el RTC a partir del reloj del sistema.

Para volver a la interpretación UTC, de nuevo con la hora del sistema correcta:

sudo timedatectl set-local-rtc 0

Antes de hacerlo debemos asegurarnos de que Windows también vaya a interpretar el reloj de forma compatible. No alternamos estos dos comandos según cuál parezca arreglar la pantalla en ese momento.

No debemos desactivar la sincronización por Internet en ambos sistemas como solución permanente. Alinear el RTC y mantener la hora sincronizada resuelve problemas diferentes, y necesitamos las dos cosas bien configuradas.

Si el problema vuelve después de apagar el equipo

Repetimos la comprobación tras reiniciar Linux y después de alternar con Windows. Si sólo ocurre en el segundo caso, volvemos a revisar la interpretación del RTC. Si aparece incluso sin arrancar Windows, no tiene sentido seguir atribuyéndoselo.

Si el firmware también pierde la fecha después de desconectar el equipo de la corriente, conviene revisar el reloj del hardware y su alimentación antes de cambiar más ajustes de Linux. En una máquina virtual puede intervenir la sincronización del hipervisor, que requiere revisar su configuración por separado.

Con estas comprobaciones sabremos si debemos corregir la zona, recuperar la sincronización o alinear el RTC. Así evitaremos poner el reloj a mano cada vez que encendemos el ordenador. ¡Un saludo!