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" <[EMAIL PROTECTED]> To: "Debian en fran�ais" <[email protected]> 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://[EMAIL PROTECTED] > Association .DLL http://altern.org/dll > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
