Rédigé par Rédaction CyberSDF / 19 September 2026

Dual boot Windows 11 et Linux : supprimer l’heure décalée après chaque redémarrage

Windows 11 affiche 14:00, Debian affiche 15:00, sur la même machine et au même instant. La ligne RTC in local TZ: yes renvoyée par timedatectl désigne la cause : Windows 11 a écrit l’heure locale dans la puce RTC de la carte mère, Linux a relu cette valeur comme de l’UTC et lui a appliqué une seconde fois le décalage de fuseau. Pour Europe/Paris, l’écart vaut exactement +1 h de fin octobre à fin mars, et +2 h le reste de l’année.

timedatectl | grep -i local

RTC in local TZ: yes

L’écart égale le décalage du fuseau, jamais une dérive de quelques secondes

Une machine possède deux horloges distinctes. La puce RTC compte les années, mois, jours, heures, minutes et secondes, sans notion de fuseau horaire ni d’heure d’été. Le système d’exploitation décide comment interpréter ce compteur. Linux lit la RTC suivant la troisième ligne du fichier /etc/adjtime ; la page de manuel adjtime_config(5) précise que les valeurs admises sont UTC ou LOCAL, et que le mode par défaut est UTC quand le fichier est absent.

Windows 11 ne connaît pas ce fichier et part du principe inverse : la documentation systemd et le wiki Arch Linux rappellent que Windows traite la RTC comme de l’heure locale par défaut. Une RTC contenant 14:00 est donc lue 14:00 par Windows, et 14:00 + UTC+01:00 = 15:00 par Linux en janvier. Un décalage de une ou deux heures exactement, jamais douze minutes, signe ce conflit de référentiel et non une pile CMOS fatiguée.

L’écart peut rester invisible. Si la synchronisation réseau est active, Linux corrige son horloge système quelques secondes après le démarrage et l’affichage redevient juste. La RTC, elle, n’est pas forcément remise d’aplomb, et le décalage réapparaît au redémarrage suivant, en particulier sur une machine Windows privée de réseau. Constaté sur Debian 12 (bookworm, systemd 252.39) et Ubuntu 24.04 (noble, systemd 255.4).

timedatectl nomme le mode de la puce sur la ligne « RTC in local TZ »

timedatectl interroge le service systemd-timedated et affiche l’état des deux horloges. La page de manuel timedatectl(1) documente cette sortie, avec la ligne finale qui tranche :

timedatectl

Local time: Thu 2024-01-11 14:04:22 CET
Universal time: Thu 2024-01-11 13:04:22 UTC
RTC time: Thu 2024-01-11 13:04:22
Time zone: Europe/Paris (CET, +0100)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

Dans cet état correct, RTC time et Universal time portent la même valeur, et Local time en diffère du décalage du fuseau. Quand RTC in local TZ: yes s’affiche à la place, la puce est interprétée comme de l’heure locale. Le filtre grep ne sert qu’à isoler cette ligne sur un écran chargé.

timedatectl | grep -i local

RTC in local TZ: no

Deux corrections possibles, une seule tient au changement d’heure

Aligner les deux systèmes suppose de choisir une référence unique pour la puce. Les deux voies fonctionnent au démarrage, mais la documentation systemd n’en recommande qu’une.

Procédure côté Linux : timedatectl set-local-rtc 0

Les étapes suivantes se lisent dans cet ordre. La dernière étape de chacune indique ce qui doit apparaître à l’écran avant de passer à la suivante.

1. Vérifiez que l’horloge système est juste, car set-local-rtc écrit la valeur du système dans la puce.

   sudo timedatectl set-ntp true
   timedatectl | grep -E 'synchronized|NTP'
   

   Ce que vous devez voir :

   System clock synchronized: yes
   NTP service: active
   

   Écrire dans la puce une horloge système fausse graverait l’erreur dans la RTC. Ne continuez pas si synchronized vaut no ; attendez la fin de la synchronisation réseau.

2. Basculez la puce en UTC. L’argument est un booléen : 0 pour l’UTC, 1 pour l’heure locale.

   sudo timedatectl set-local-rtc 0
   

   Ce que vous devez voir : rien. La commande réussit en silence. Le contrôle se fait à l’étape suivante.

3. Relisez l’état.

   timedatectl | grep -i local
   

   Ce que vous devez voir :

   RTC in local TZ: no
   

   Toute autre valeur signifie que la commande n’a pas été appliquée ou que l’accès privilégié a échoué.

4. Confirmez le contenu du fichier de configuration. La page de manuel signale que set-local-rtc réécrit la troisième ligne de /etc/adjtime.

   tail -n 1 /etc/adjtime
   

   Ce que vous devez voir :

   UTC
   

5. Contrôlez que la puce contient bien l’UTC et non l’heure locale. Dans la sortie complète, les deux lignes doivent coïncider à la seconde près.

   timedatectl
   

   Ce que vous devez voir : RTC time et Universal time identiques, par exemple 13:04:22 pour les deux, tandis que Local time affiche 14:04:22.

6. Redémarrez, laissez Windows 11 démarrer une fois, revenez sous Linux et relancez l’étape 5. Ce que vous devez voir : la ligne Local time de Linux correspond à l’heure affichée par Windows 11 au même fuseau.

L’option --adjust-system-clock, documentée dans timedatectl(1), inverse le sens de la copie : la valeur de la puce est alors recopiée dans l’horloge système. Elle se justifie quand la RTC est la source fiable et le système faux, cas rare sur une machine synchronisée par réseau.

Le même réglage côté Windows 11 : RealTimeIsUniversal

Windows 11 doit lire la puce comme de l’UTC, sinon il réécrira de l’heure locale au prochain démarrage et le décalage reviendra. La clé concernée, documentée par le wiki Arch Linux, se trouve sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation. Dans une invite de commandes lancée en administrateur :

reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f

Ce que vous devez voir : le message de réussite de Windows, puis la confirmation en relisant la valeur.

reg query "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
    RealTimeIsUniversal    REG_DWORD    0x1

Redémarrez Windows 11. Au démarrage suivant, il interprète la puce comme de l’UTC et affiche l’heure locale du fuseau. Si l’affichage reste faux, corrigez l’heure une fois depuis Windows : il écrit alors la valeur UTC dans la puce. Le type REG_DWORD est celui employé par la documentation systemd et par le wiki Arch Linux ; la variante REG_QWORD présente dans certains tutoriels pour Windows 64 bits n’a pas pu être confirmée dans une source officielle.

Le piège : set-local-rtc 1 est documenté comme « not fully supported »

La commande timedatectl set-local-rtc 1 fait disparaître le symptôme sans toucher à Windows, puisque les deux systèmes interprètent alors la puce comme de l’heure locale. La page de manuel timedatectl(1) met pourtant en garde en toutes lettres : maintenir la RTC en heure locale n’est pas entièrement pris en charge et créera divers problèmes lors des changements de fuseau et des ajustements d’heure d’été, et recommande de garder la RTC en UTC chaque fois que c’est possible.

Une modification de comportement aggrave le tableau. Depuis systemd 216, quand la RTC est configurée en heure locale, systemd n’écrit plus jamais dans la puce, afin de ne pas désorienter Windows au démarrage suivant, et il n’informe plus le noyau du fuseau courant. Deux conséquences observables : la dérive de la puce n’est plus corrigée depuis Linux, et les horodatages des systèmes de fichiers FAT et exFAT, qui ne stockent pas de fuseau, sont systématiquement interprétés comme de l’UTC. Une clé USB échangée entre les deux systèmes affiche des heures de fichier décalées.

E: Release file … is not valid yet : quand l’horloge retarde, apt refuse le dépôt

Un décalage d’une ou deux heures ne casse pas naviguer, mais il suffit à bloquer les mises à jour. Quand l’horloge système retarde sur la date inscrite dans le fichier Release d’un dépôt, apt update rejette l’ensemble de ce dépôt avec un message qui ne parle ni de réseau ni de paquets.

E: Release file for https://security.ubuntu.com/ubuntu/dists/jammy-security/InRelease is not valid yet (invalid for another 58min 27s). Updates for this repository will not be applied.

La cause est l’horloge, pas la signature du dépôt. Le remède tient en deux commandes, avant toute autre tentative.

sudo timedatectl set-ntp true
timedatectl | grep synchronized
sudo apt update

Ce que vous devez voir : System clock synchronized: yes avant de relancer apt update. Contourner ce contrôle en désactivant la vérification des dates masque le symptôme sans traiter l’horloge, et le message revient au redémarrage suivant. La gestion des dépôts est détaillée dans dépôts APT sous Debian.

Questions fréquentes sur la RTC et le dual boot

Pourquoi le décalage n’apparaît-il qu’après un changement d’heure ?

Parce que l’écart suit le fuseau. Une puce en heure locale relue comme de l’UTC produit +1 h en heure d’hiver et +2 h en heure d’été pour Europe/Paris. Tant que les deux systèmes sont d’accord sur le mode, le décalage est nul ; il se révèle au basculement de fin mars ou de fin octobre, ou après une réinstallation de Linux. Le wiki Arch Linux note que beaucoup de distributions règlent la puce en heure locale si elles détectent Windows pendant leur installation, ce qui explique un décalage qui survient sans qu’aucun réglage n’ait été modifié.

Peut-on laisser Linux en UTC et Windows en heure locale ?

Non, pas durablement. Les deux systèmes écrivent tour à tour dans la même puce au démarrage et à l’arrêt. Chacun réinterprète la valeur écrite par l’autre selon sa propre convention, et l’heure se décale un peu plus à chaque passage. La puce doit suivre une seule référence, et il faut que les deux systèmes s’accordent dessus.

timedatectl échoue et parle de connexion : pourquoi ?

timedatectl dialogue avec systemd-timedated par D-Bus et ne travaille pas sur le matériel directement. Dans un chroot ou un conteneur sans D-Bus actif, la commande ne peut pas joindre ce service ; la page de manuel et le wiki Arch Linux renvoient alors vers hwclock, qui agit sur la puce sans passer par systemd. hwclock --systohc écrit l’horloge système dans la RTC, et hwclock --show l’affiche.

Faut-il une valeur REG_QWORD au lieu de REG_DWORD sur Windows 64 bits ?

La valeur documentée est un REG_DWORD valant 1, y compris sur Windows 11 en 64 bits. Certains tutoriels recommandent un REG_QWORD ; cette variante n’a pas pu être confirmée dans une source officielle. Après la modification, la relecture par reg query doit afficher REG_DWORD 0x1 sur la bonne clé, et non sous WOW6432Node.

Comment distinguer le conflit de fuseau d’une pile CMOS usée ?

Sur la valeur de l’écart. Un conflit de référentiel produit exactement une ou deux heures, symétriques en signe, et la date reste la bonne. Une pile CR2032 usée remet la RTC à une date ancienne, souvent une année ronde comme 2000 ou 2001, et l’écart persiste même quand un seul système est installé. Dans le premier cas, timedatectl set-local-rtc 0 et la clé RealTimeIsUniversal règlent la situation ; dans le second, la pile doit être remplacée.

Après le remplacement ou le réglage, la commande de contrôle reste toujours la même :

timedatectl | grep -i local