Re: mise à l'heure pour dual-boot
Normalement les configurations d'Unix pour PC considère au démarrage que l'horloge CMOS contient une heure locale (et non une heure UTC comme généralement constaté sur les autres systèmes). Ceci est une tradition remontant aux premiers systèmes d'exploitation pour PC, IBM PC-DOS, puis Microsoft MS-DOS, IBM OS/2, SCO...
Bref c'était une erreur de conception au départ lors de la spécification des BIOS par IBM: le BIOS du PC ne savait pas faire de translation d'heure locale quand il lisait ou écrivait le CMOS, car il ne gérait qu'une heure locale dans ses variables internes utilisées par l'horloge logicielle utilisée ensuite.
D'autre part, cette configuration d'horloge logicielle était nécessaire car les premiers PC n'avait pas d'horloge temps-réel, et que les premiers modèles apparus avec une horloge "sauvegardée" utilisaient un circuit pour montre à bas prix et trop lent pour être utilisable par les logiciels du PC. D'autre part un accès trop fréquent à cette horloge CMOS l'aurait complètement déréglée, rendant cette "sauvegarde" inopérante. Les PC devaient donc être être remis à l'heure à chaque démarrage jusqu'à l'apparition de l'horloge CMOS qui n'était ensuite utilisée par le BIOS que lors du boot ou d'un changement de l'heure locale.
Rien n'a été fait pour gérer dans les BIOS une variable de zone locale (c'était trop compliqué à intégrer dans le BIOS, qui par ailleurs aurait du gérer toutes les zones locales d'heure d'été, ce qui ne peut pas être fixé dans le silicium, les règles de gestion de l'heure d'été étant trop changeantes et politiques dans chaque pays qui applique cette heure certaines années et pas d'autres, ou avec des décalages d'une demi-heure, ou encore à des dates fixées chaque année pour des raisons culturelles ou religieuses). Il n'y avait pas Internet pour tout le monde à l'époque. Donc connaitre et diffuser ces règles au plan mondial était passablement compliqué pour les éditeurs de logiciels, et encore plus pour les utilisateurs, qui eux ne connaissent généralement bien que l'heure locale qu'ils appliquent au moment où ils se servent de leur PC, et leur demander d'éditer un fichier de configuration pour l'heure d'été était trop compliqué. Microsoft a omis de fournir des commandes supplémentaires pour régler la date autrement qu'en fixant l'heure locale. Il aurait pu prévoir une commande demandant à l'utilisateur si l'heure d'été était utilisée au moment de la saisie de l'heure avec TIME, mais il fallait aussi une heure pour indiquer l'heure UTC (Microsoft aurait pu régler ça quand il a introduit la commande COUNTRY dans son CONFIG.SYS, mais il ne l'a pas fait)! Bref l'heure UTC (anciennement heure GMT) est impossible à déterminer dans ces vieux OS, qui ne savent gérer que l'heure locale, et l'inscrivent bêtement dans l'horloge CMOS (qui d'ailleurs ne gère pas non plus le siècle courant). Je sauterai ici tout ce qui s'en est suivi sur le bug de l'an 2000...
Microsoft et IBM aurait pu aussi négocier avec les constructeurs de BIOS pour réserver un bit dans la CMOS pour indiquer que l'heure stockée était en format UTC et non une heure locale. Personne ne l'a fait ou standardisé. Les fabriquants de BIOS auraient pu se concerter et spécifier cet usage, à charge ensuite des éditeurs de systèmes d'exploitation de l'utiliser pour réger correctement l'heure. Tout ce flou et ce manque de réflexion sur la gestion de l'heure sur le PC explique la complexité de résolution des bogues liés à l'an 2000. Au passage, devant ce cauchemar, il est étonnant que la résolution du bogue s'est faite de façon non concertée, et chacun a pondu sa solution. Pourquoi diable n'avoir pas refixé une bonne fois les règles dans un consortium qui aurait réglé les spécifications de compatibilité pour gérer enfin l'heure UTC au sein du BIOS ?
Le changement est apparu avec Windows 3.11 (pas avant!), qui offrait enfin une façon simple de gérer les fuseaux horaires, et de calculer l'heure UTC requise par les protocoles réseau et le partage de fichiers. Depuis sur les PC, l'heure UTC est DEDUITE de l'heure locale fixée par le matériel. Depuis OS/2 et Windows NT puis Windows 95 l'OS gère sa propre horloge logicielle UTC plus précise, et indépendante de l'horloge locale par logiciel du BIOS (partagée avec MSDOS) et de l'horloge matérielle du CMOS. On a depuis lors 3 horloges distinctes sur tous les systèmes d'exploitation dont Linux...
Maintenant comment régler l'écart entre heure locale et heure UTC: c'est le role de la spécification ANSI sur la variable d'environnement TZ (et la fonction tzset() gérant les "timezones").
Traditionnellement on indique uniquement un sigle en lettres indiquant le nom de la zone d'hiver (à afficher avec l'heure locale si on est en hivers), suivie du décalage en heures (ou heures et minutes) avec l'heure UTC (décalage négatif à l'Est de GMT en Europe, Afrique, Asie, Australie et Nouvelle-Zélande, positif à l'Ouest de GMT en Amérique et zone Pacifique à la date Américaine). Par exemple, pour l'Europe occidentale continentale (sauf UK et Portugal) on indique "CET-1". On peut faire suivre cette indication par un sigle différent pour l'heure d'été. Par exemple "CET-1CEST".
Note: il y a une ambiguité sur la lettre à ajouter avant le T final. CET signifie "Central European Time". CST signifie "Central Standard Time" en Amérique du Nord ou en Australie (d'où la nécessité de rendre le sigle non ambigu avec l'indication numérique du fuseau horaire après le sigle). Les Nords-Américains remplacent le "S" central par un "D" quand ils appliquent l'heure d'été (qu'ils appelle "daylight-saving time" ou DST qu'on traduit par "heure de préservation de la lumière du jour"), mais pas les Australiens ou Néo-zélandais qui appliquent l'heure d'été dans certaines zones seulement, et qu'ils appellent "summer time" ou heure d'été, car elle s'applique à l'inverse de l'hémisphère Nord (autrement dit l'heure d'été commence au quatrième trimestre d'une année et s'achève l'année suivante au premier trimestre): pour eux le D de DST ne signifie rien, et le S de "summer time" se confond avec le S qu'on trouve dans leurs zones d'hivers "standard": WST (Western Standard Time), CST (Central Standard Time), EST (Eastern Standard Time). Aussi, les Australiens (mais d'autres aussi) ne distinguent pas le sigle de l'heure d'été. Cela pose quand même un problème entre les deux Etats limitrophes d'Australie du Sud (à Adélaïde, qui utilise le fuseau CST et applique l'heure d'été CST), et d'Australie du Nord (à Darwin, dans le même fuseau CST, mais qui n'appliquent pas l'heure d'été à cause de sa position sub-tropicale ou les notions d'été et d'hiver se confondent!). Moralité: il ne faut sa se fier à un seul sigle: par exemple CST est ambigu et ne désigne que le nom du fuseau horaire standard connu localement, et à Chicago on précisera "CST-6CDT", à Darwin on utilisera "CST+10", à Adélaïde "CST+10CSST" ou "CST+10SAST".
Tout cela est très bien mais ça n'indique toujours pas quand on applique l'heure d'été. Classiquement, c'est un fichier de base de données qui détermine les dates et heures de basculement à l'heure d'été. Sous Windows 95 et NT, cette base est stockée dans la base de registres dans HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\TimeZone. Un utilitaire "tzedit.exe" permet d'y inscrire de nouvelles règles ou de modifier les règles. Malheureusement, Windows ne permet pas de conserver une base historique de ces changements qui interviennent pour des raisons politiques et religieuses (allez voir un peu ce qui se passe en cas de changement de régime, d'indépendance d'un pays, en Australie, et en Israel ou en Iran où un autre calendrier religieux détermine les règles, ou quand tout bonnement les règles sont fixées tous les ans par décision politique...): l'utilitaire ne permet de fixer que deux dates dans la même année non spécifiée pour un même fuseau spécifié. Les règles de l'heure d'été ne sont simples qu'en Europe occidentale, et aux Etats-Unis, ou dans les pays tropicaux et équatoriaux qui traditionnellement n'appliquent pas l'heure d'été. Et encore il faut savoir qu'il y a des exceptions. Et il y a ainsi dans le monde une bonne CENTAINE de règles. Sous Unix et Linux la configuration est stockée géléralement dans un répertoire "timezone" ou "zoneinfo" de "/usr/lib" ou "/usr/share/lib": voir le man de la commande "zic(1)" ou de la fonction "tzset(3)". Unix permet de gérer TOUTES les règles du monde dans ces fichiers, et d'en garder un historique complet (mais il faut mettre à jour régulièrement ces fichiers ou les éditer manuellement, donc attention au format utilisé!)
Dans ton cas, tu indiques que tu affiches l'heure suivante: "date"="ven 09 jun 2000 01:39:54 CEST", cela indique que l'heure affichée est dans la zone CEST (autrement dit "Central European Summer Time"), donc tu as bien appliqué l'heure d'été au 9 juin 2000 appliquable en France (une commande "date -u" te donnerait l'heure "="ven 08 jun 2000 23:39:54 UTC", c'est à dire avec 2 heures de décalage entre l'heure française d'été et l'heure UTC).
Cela n'est par contre pas conforme avec l'indication "hwclock"="Thu Jun 8 23:39:02 2000 -0.189095 seconds" donnée par lecture de l'horloge matérielle (il ne devrait y avoir qu'une heure de décalage en plus ou en moins, mais seulement après un basuclement d'heure d'été/hivers).
Si tu as suivi ma discution, tu noteras que ce doit être l'heure stockée également dans l'horloge CMOS gérée par le BIOS. En cas de passage à l'heure d'hivers, ton système devrait modifier l'heure dans la CMOS pour garder la synchronisation. Comme c'est un processus longuet (l'horloge CMOS est TRES lente à réagir), Linux peut être configuré pour ne pas le faire (comme le fait en standard Windows 95).
Dans ce cas, Linux garderait son heure UTC interne et ne toucherait pas à l'heure CMOS qui resterait sur l'heure locale d'été ou d'hivers, ce qui pose un problème évident si ton système plante et redémarre: l'horloge CMOS peut être resté incorrectement en heure d'hivers ou d'été. Heureusement, il y a un standard quand même à ce niveau: la mémoire CMOS contient un bit réservé (mais seulement sur certains PC disposant de BIOS récents) permettant de savoir si le dernier réglage fait par Windows ou Linux de l'horloge CMOS était une heure d'été ou d'hivers. Le BIOS ne gère pas ce bit, mais il se contente de le garder.
Aussi, Linux propose une autre solution OPTIONNELLE (conforme à ce qu'on trouve sur d'autres systèmes Unix non PC), qui est de conserver dans l'horloge CMOS non pas l'heure locale qui passe d'été en hivers, mais l'heure UTC. Cette solution a l'avantage de ne pas requérir l'utilisation de l'horloge CMOS en cours de fonctionnement du système (cela donne un très léger plus en performance de l'horloge système, et améliore la stabilité de l'horloge matérielle dans le temps) mais le défaut d'être complètement incompatible avec Windows ou les autres systèmes, car il n'y a aucun standard défini au sein de la mémoire CMOS et reconnu par le BIOS, permettant de savoir que l'heure stockée est une heure UTC et non une heure locale (le seul standard existant est de savoir si l'heure locale est l'heure locale d'hivers ou l'heure locale d'été).
Tu remarqueras que si tu bootes ton PC et vas dans la configuration du BIOS, ton PC "n'est pas à l'heure". En fait il a été réglé à l'heure UTC quand tu a fixé l'heure locale depuis Linux. C'est très bien si Linux est ton seul système d'exploitation.
Si tu rétablit l'heure locale au sein de l'utilitaire de configuration du BIOS et que tu bootes sous Windows, OS/2, SCO, UnixWare, AiX-386, Solaris-386 ou DGuX, ton système sera bien à la bonne heure. Mais si tu bootes sous Linux, ton système aura deux heures d'avance en été (CEST), ou 1 heure en hivers (CET), ce qui démontre que l'option proposée par Linux n'est pas standard et ne doit pas être utilisée en cas de coexistence de plusieurs systèmes! Bref, dans le cas d'un interfonctionnement Windows/Linux il ne faut pas l'utiliser et reconfigurer Linux avec son comportement par défaut.
> ----- Original Message -----
From: "christian grimaux" <christian.grimaux@free.fr>
To: "Debian en français" <debian-french@lists.debian.org>
Sent: Friday, June 09, 2000 2:11 AM
Subject: mise à l'heure pour dual-boot
> Suite à une installation un peut précipité, j'ai mal configuré l'heure.
> Je fonctionne en dual-boot, Win-Linux (debian slink noyau 2.0.36).
> Depuis, Linux remet systématiquement à l'heure (mauvaise) l'horloge
> (cmos) et win est en retard.
> hwclock me donne :
> Thu Jun 8 23:39:02 2000 -0.189095 seconds
> et date me donne
> ven 09 jun 2000 01:39:54 CEST
> La lecture du Mini HOWTO Clock et des pages de man (dont hwclock en
> anglais :( ) ne m'ont pas été d'un grand secour. Les autres info que
> j'ai pus glaner cite soit des machines toujours connecté, soit avec un
> seul os.
> Alors :
> Comment faire pour que seul un des deux systèmes remette l'horloge à
> l'heure?
> Comment règler l'heure pour avoir le bon fuseau ?(c'est lequel?)
> (les propositions et les explications fournies au démarrage sont plutot
> obscures (à moins que ce ne soit moi qui le soit?))
> A+ et Merci.
> --
> Christian GRIMAUX mailto://christian.grimaux@free.fr
> Association .DLL http://altern.org/dll
>
>
> --
> To UNSUBSCRIBE, email to debian-french-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: