Hallo nochmal, so habe ich mir das vorgestellt: kaum rühr' ich dran, schon geht es nicht mehr. Aber erstmal danke für die ausführlichen Antworten! Ich habe meine Hardware-Uhr auf UTC umgestellt, läuft soweit auch prima, nur: Nach einem Neustart geht die Uhr um zwei Stunden nach. In der Datei `/etc/adjtime' steht vor dem Herunterfahren in der letzten Zeile: "UTC". Nach dem Neustart steht da: "LOCAL". Klar, daß dann die Uhr 2 Stunden nachgeht. Was muß ich ändern, damit das "UTC" in `/etc/adjtime' erhalten bleibt? Danke vorab, Bertram ____________________ Hier ein paar Programmausgaben: VOR dem Neustart: # netdate -l 10000 tcp ptbtime1.ptb.de ptbtime2.ptb.de Trying 192.53.103.103... ptbtime1.ptb.de -0.490 Fri Apr 12 18:03:36.000 Trying 192.53.103.104... ptbtime2.ptb.de -0.708 Fri Apr 12 18:03:36.000 Trying 192.53.103.103... ptbtime1.ptb.de +0.079 Fri Apr 12 18:03:37.000 # hwclock -r Fre 12 Apr 2002 18:03:46 CEST -0.129561 Sekunden # hwclock -wu # hwclock -r Fre 12 Apr 2002 18:03:52 CEST -0.709723 Sekunden # date Fre Apr 12 18:03:54 CEST 2002 # cat /etc/adjtime -1504.953369 1018627428 0.000000 1018627428 UTC # NACH dem Neustart: # hwclock -r Fre 12 Apr 2002 16:11:07 CEST -0.214381 Sekunden # date Fre Apr 12 16:11:08 CEST 2002 # cat /etc/adjtime -1504.953369 1018620536 0.000000 1018627428 LOCAL # -- Bertram Scharpf

Hallo, Danke nochmal für Eure Antworten. Jetzt hab's sogar ich verstanden. Ich fasse zusammen. (Wenn Fehler drin sind, verbessere man mich.) Suchbegriffe: Systemzeit Hardwarezeit Zeitzonen Europe/Berlin system time hardware clock time zone UTC GMT hwclock date uhr stellen uhrzeit einstellen netdate PTB Braunschweig I. Hardwareuhr Im Rechner eingebaut ist eine Quarzuhr, die sich im wesentlichen nicht unterscheidet von dem, was z. B. in einer »swatch« steckt. Unter Windows wird schlicht diese Uhr angezeigt, und im März/im Oktober wird sie um eine Stunde vor/zurückgestellt. Diese Uhr sehe ich auch im BIOS-Menü laufen, wenn ich vor dem Booten `Del'/`Strg-Alt-Esc' drücke. II. Systemuhr Die Genauigkeit dieser Quarzuhr ist vergleichsweise schlecht gegenüber der des Prozessors. Unsere Freunde in Redmond sind bekanntermaßen mit der schlampigen Lösung zufrieden, aber Linux zählt selber eine Zeit mit, die Systemzeit. Diese Uhr kann angezeigt und gestellt werden mit dem Befehl `date'. Die Systemzeit enthält nicht nur Datum, Stunden, Minuten und Sekunden. Sie enthält auch eine Information über die Zeitzone, in der sich der Rechner befindet. Bei der Kommunikation im Netz können somit zwei Zeitpunkte in Stuttgart und in Sydney verglichen werden. Die zusätzliche Information ist die _Abweichung in Stunden_ von der Zeit auf dem nullten Längengrad: der "Greenwich Mean Time" (GMT), unter Unix genannt: "Universial Time Coordinated" (UTC). Mit der Option `--utc' oder `-u' kann man sich diese Zeit angeben lassen. Das sieht dann so aus: $ date Fre Apr 12 21:53:54 CEST 2002 $ date -u Fre Apr 12 19:53:57 UTC 2002 $ III. Stellen der Hardwareuhr Die Hardwareuhr kann nun entweder in meiner Zeitzone laufen, so wie meine Armbanduhr, oder sie wird auf UTC gestellt. Die Information, welcher Zeitzone sie angehört, ist in der Hardwareuhr nicht enthalten. Daher ist es besser für Rechner, auf denen auch ein Windows läuft, sie auf meine Zeitzone einzustellen. Unter Linux stellt und liest man die Hardwareuhr, indem man die Systemzeit auf die Hardwareuhr überträgt und umgekehrt. Dies macht der Befehl `hwclock'. Anzeigen lassen kann man sich die Hardwareuhr auch mit der Option `-r'. # hwclock -r Fre 12 Apr 2002 22:05:56 CEST -0.397095 Sekunden # Beim Übertragen Hardwareuhr->Systemzeit und umgekehrt muß nun angegeben werden, ob die Hardwareuhr als lokale Zeit oder als UTC (GMT) aufgefaßt werden soll. Dies geschieht wieder mit der Option `--utc' oder `-u'. Beim Bootvorgang wird die Systemzeit von der Hardwareuhr her gestellt, ebenfalls mit dem Befehl `hwclock'. Auch hier muß natürlich angegeben werden, wie die Hardwareuhr aufgefaßt wird. Das Verfahren, `hwclock' seine Parameter beizubringen, ist distributionsabhängig. Bei SuSE trägt man in `/etc/rc.config' ein: GMT="-u" statt GMT="--localtime" oder man läßt YAST dies machen. Die Informationen, wie die Hardwareuhr von der Systemuhr abweicht, speichert `hwclock' in `/etc/adjtime'. Darin steht nicht nur, als welche Zeitzone sie aufgefaßt wird. Beim Herunterfahren des Systems wird die Abweichung zur Systemzeit gemessen, ein Korrekturfaktor errechnet, und dieser beim nächsten Hochfahren berücksichtigt, wenn aus der Hardwareuhr wieder eine Systemzeit gemacht wird. IV. Stellen der Systemzeit möglichst genau Die Physikalisch-Technische Bundesanstalt in Braunschweig betreibt eine Cäsium-Uhr. Deren Zeit strahlt sie aus z. B. als Funksignal, das von den inzwischen sehr verbreiteten Funkuhren empfangen wird. Außerdem verschickt die Anstalt das Zeitsignal im Netz. Von Linux wird das gelesen mit # netdate tcp ptbtime1.ptb.de ptbtime2.ptb.de Nun ist die Systemuhr gestellt; um die Zeit auch über den nächsten Reboot hinaus zu retten, und um verquere Korrekturfaktoren in `/etc/adjust' zu vermeiden, sollte man noch die Hardwareuhr danach stellen. # hwclock --systohc --utc Wer ISDN hat, ist vielleicht schon einmal auf den Gedanken gekommen, seine Uhr nach der dort übertragenen Zeit zu stellen. Das geht auch. Aber: die ISDN-Zeit kann in der Genauigkeit mit der aus Braunschweig nicht mithalten. Soweit meine ich, war dies das wichtigste. Ich hoffe, es sind keine Fehler drin. Bertram -- Bertram Scharpf

Hallo, On Fri, 12 Apr 2002, Bertram Scharpf wrote:

Die Systemzeit enthält nicht nur Datum, Stunden, Minuten und Sekunden. Sie enthält auch eine Information über die Zeitzone, in der sich der Rechner befindet.

Nicht ganz. Die Systemzeit ist einfach ein Zaehler, der die Sekunden seit dem 1.1.1970 0:0:00 zaehlt. Alle anderen Infos koennen und werden durch die Funktionen gmtime/localtime und der Angabe der Zeitzone (z.B. CEST) berechnet. Die Zeitzonen werden in den Dateien in /usr/share/zoneinfo definiert (diese sind allerdings in ein binaeres Format "kompiliert" auslesen kann man diese teilweise mittels 'zdump -v [ZEITZONE]'. Die Sommerzeit ist dabei "einfach" nur ein "Flag" das ggfs. gesetzt ist (siehe die Def. von 'struct tm' in 'man localtime'. Ob bzw. wann das flag zu setzen ist, wird in der Zoneninfo-Datei festgelegt. Weiterhin fehlt noch komplett der Hinweis auf die Schaltsekunden und auf die Umgebungsvariable 'TZ'... ==== Aus glibc-<version>/timezone/leapseconds ==== # The International Earth Rotation Service periodically uses leap seconds # to keep UTC to within 0.9 s of UT1 # (which measures the true angular orientation of the earth in space); see # Terry J Quinn, The BIPM and the accurate measure of time, # Proc IEEE 79, 7 (July 1991), 894-905. # There were no leap seconds before 1972, because the official mechanism # accounting for the discrepancy between atomic time and the earth's rotation # did not exist until the early 1970s. ==== Die Schaltsekunden werden verwendet, wenn man die Zeitzonen 'right/' verwendet (ich verwende hier z.B. TZ="right/Europe/Berlin". Seit 1972 wurden immerhin 22 Schaltsekunden eingefuegt (siehe die Ausgabe von 'zdump -v right/Europe/Berlin'). IIRC wurde das Thema vor einiger Zeit in der c't von Andreas Jaeger (einem der glibc-Entwickler, u.a. eben auch am relevanten Code) erklaert... $ TZ="right/Europe/Berlin" date; TZ="Europe/Berlin" date Sat Apr 13 06:42:00 CEST 2002 Sat Apr 13 06:42:22 CEST 2002 [..]

IV. Stellen der Systemzeit möglichst genau # netdate tcp ptbtime1.ptb.de ptbtime2.ptb.de

Hier fehlt 'localhost' als letzter host... Siehe 'man netdate'. -dnh -- It takes a million monkeys at typewriters to write Shakespeare, but only a dozen monkeys at computers to run Network Solutions. -- Patrick Delahanty

Hallo David, Am 13. Apr 2002, 06:42 Uhr schrieb David Haller:

Die Schaltsekunden werden verwendet, wenn man die Zeitzonen 'right/' verwendet (ich verwende hier z.B. TZ="right/Europe/Berlin". Seit 1972 wurden immerhin 22 Schaltsekunden eingefuegt (siehe die Ausgabe von 'zdump -v right/Europe/Berlin').

IIRC wurde das Thema vor einiger Zeit in der c't von Andreas Jaeger (einem der glibc-Entwickler, u.a. eben auch am relevanten Code) erklaert...

$ TZ="right/Europe/Berlin" date; TZ="Europe/Berlin" date Sat Apr 13 06:42:00 CEST 2002 Sat Apr 13 06:42:22 CEST 2002

Da frage ich mich allerdings, was denn nun "richtig" ist: vergleiche ich die Ausgaben beider Befehle mit dem, was meine "Atomuhr" (richtiger wäre "Uhr mit Empfänger der PTB-Zeit") anzeigt, wäre danach der zweite Wert - sprich TZ="Europe/Berlin" - korrekt. Irgendwie kann ich mir nicht vorstellen, daß die PTB über ihren Sender im Taunus was flasches verbreitet !?!? Gruß Rudi -- Computers are useless - they can only give you answers. [Pablo Picasso]

Hallo Bernd, Am 14. Apr 2002, 13:57 Uhr schrieb Bernd Brodesser:

* Rudolf Buerger schrieb am 14.Apr.2002:

...

Am 13. Apr 2002, 06:42 Uhr schrieb David Haller:

...

$ TZ="right/Europe/Berlin" date; TZ="Europe/Berlin" date Sat Apr 13 06:42:00 CEST 2002 Sat Apr 13 06:42:22 CEST 2002

...

Da frage ich mich allerdings, was denn nun "richtig" ist: vergleiche ich die Ausgaben beider Befehle mit dem, was meine "Atomuhr" (richtiger wäre "Uhr mit Empfänger der PTB-Zeit") anzeigt, wäre danach der zweite Wert - sprich TZ="Europe/Berlin" - korrekt. Irgendwie kann ich mir nicht vorstellen, daß die PTB über ihren Sender im Taunus was flasches verbreitet !?!?

Du mußt anschließen die Uhr wieder richtig stellen, und damit leben, daß die Zeiten der Dateien bis zu 22 Sekunden falsch sind.

Muß ich das jetzt so interpretieren: - TZ="Europe/Berlin" = PTB-Zeit = "offizielle" Zeit = "falsche" Zeit - TZ="right/Europe/Berlin" = "richtige" Zeit. Kann ich mir irgendwie nicht vorstellen... Gruß Rudi -- Und dann üben wir den richtigen Gebrauch der Kleinbuchstabengroßmachtaste. [Dieter Bruegmann]

On Sat, 13 Apr 2002 at 06:42 (+0200), David Haller wrote:

==== Aus glibc-<version>/timezone/leapseconds ==== # The International Earth Rotation Service periodically uses leap seconds # to keep UTC to within 0.9 s of UT1 # (which measures the true angular orientation of the earth in space); see # Terry J Quinn, The BIPM and the accurate measure of time, # Proc IEEE 79, 7 (July 1991), 894-905. # There were no leap seconds before 1972, because the official mechanism # accounting for the discrepancy between atomic time and the earth's rotation # did not exist until the early 1970s. ====

Zu dem Thema habe ich eine schöne URL: http://www.ptb.de/de/org/4/43/432/ssec.htm Laut dieser Angabe wurden seit 1970 22 Sekunden _eingefügt_, d. h. die Zeit mit Schaltsekunden muss "mehr" sein wie die ohne.

Die Schaltsekunden werden verwendet, wenn man die Zeitzonen 'right/' verwendet (ich verwende hier z.B. TZ="right/Europe/Berlin". Seit 1972 wurden immerhin 22 Schaltsekunden eingefuegt (siehe die Ausgabe von 'zdump -v right/Europe/Berlin').

IIRC wurde das Thema vor einiger Zeit in der c't von Andreas Jaeger (einem der glibc-Entwickler, u.a. eben auch am relevanten Code) erklaert...

Weißt Du zufällig die Ausgabe noch? Ich hoffe, das war letztes Jahr, weil davon habe ich die c'ts auf CD-ROM (und die von dem habe ich sowieso noch als Papier).

$ TZ="right/Europe/Berlin" date; TZ="Europe/Berlin" date Sat Apr 13 06:42:00 CEST 2002 Sat Apr 13 06:42:22 CEST 2002

Und genau das kann nicht stimmen! Die Zeit mit Schaltsekunden muss mehr sein, also in dem Fall Sat Apr 13 06:42:22 CEST 2002, d. h. die Ausgabe, die mit TZ="Europe/Berlin" erzeugt wurde. Also muss die Zeit mit "right" die _ohne_ Schaltsekunden sein. Ein kleines C-Programm soll nun klären, welchen Wert die time()-Funktion zurückliefert: ,----[ zeit.c ]- | #include | #include | #include | | int main (int argc, char *argv[]) { | time_t sec_since_1970; | long tage, stunden, minuten, sekunden; | | time(&sec_since_1970); | | tage = sec_since_1970 / 24 / 3600; | stunden = (sec_since_1970 - tage * 24 * 3600) / 3600; | minuten = (sec_since_1970 - tage * 24 * 3600 | - stunden * 3600) / 60; | sekunden = (sec_since_1970 - tage * 24 * 3600 | - stunden * 3600 - minuten * 60); | | printf("UTC: %02ld:%02ld:%02ld\n", stunden, minuten, sekunden); | | puts("\ndate mit Europe/Berlin :"); | system("TZ=Europe/Berlin date"); | puts("\ndate mit right/Europe/Berlin:"); | system("TZ=right/Europe/Berlin date"); | | return(0); | } `---- Die Ausgabe (unabhängig von der $TZ-Variablen): berwal [~] $ zeit UTC: 18:59:16 date mit Europe/Berlin : Son Apr 14 20:59:16 CEST 2002 date mit right/Europe/Berlin: Son Apr 14 20:58:54 CEST 2002 D. h. time() liefert immer die Zeit zurück, die ohne "right" generiert wurde, also die, die mit der offiziellen PTB-Zeit übereinstimmt (-> Funkuhr), also die Zeit _mit_ Schaltsekunden. Insofern liefert right/ die "falsche" Zeit, die nicht mit time() übereinstimmt. Jetzt frage ich mich nur, wozu man die überhaupt braucht? Gruß, Bernhard PS: Mag sein, dass mein Programm etwas unständlich ist, aber mir ist es auf die Schnelle nicht anders eingefallen und der Zweck ist ja auch erfüllt ... -- "Unix is the most user friendly system I know, the point is the it is really selective about who is indeed its friend." -- Luigi Genoni

* Bernhard Walle schrieb am 14.Apr.2002:

...

On Sat, 13 Apr 2002 at 06:42 (+0200), David Haller wrote:

...

Laut dieser Angabe wurden seit 1970 22 Sekunden _eingefügt_, d. h. die Zeit mit Schaltsekunden muss "mehr" sein wie die ohne.

[...]

...

...

$ TZ="right/Europe/Berlin" date; TZ="Europe/Berlin" date Sat Apr 13 06:42:00 CEST 2002 Sat Apr 13 06:42:22 CEST 2002

Und genau das kann nicht stimmen!

Die Zeit mit Schaltsekunden muss mehr sein, also in dem Fall Sat Apr 13 06:42:22 CEST 2002, d. h. die Ausgabe, die mit TZ="Europe/Berlin" erzeugt wurde. Also muss die Zeit mit "right" die _ohne_ Schaltsekunden sein.

Nein, es ist schon richtig was David geschrieben hat. Die Systemuhr sagt es sind 1018672942 s seit dem 1.1.1970 0:00 Uhr UTC vergangen. Wenn man keine Schaltsekunden brücksichtigt, dann ist das der 13. Apr 2002 6:42:22 Mitteleuropäischer Sommerzeit. Wenn man aber die Schaltsekunden berücksichtigt, dann ist es erst 6:42:00, denn die 22 Sekunden werden für die Schaltsekunden verbraten, die es zwichendurch gegeben hat.

Durch die Änderung von $TZ änderst Du nichts an der Systemzeit, und die besteht aus Sekunden seit 1.1.1970. Wenn Du auf right umstellst, dann mußt Du auch die Uhrzeit verstellen, denn die stand ja auf der richtigen aktuellen Zeit, nur die Vergangenheit ist falsch. Bei der Umstellung wird die Vergangenheit aber nicht verändert, sonder die aktuelle Zeit, die ja eigentlich richtig ist.

Ui Ui Ui! Da habe ich ja nen wunden Punkt getroffen. Dabei wollte ich eigentlich nur wissen, wie ich auf meinem Server die Uhrzeiten und Zeitszonen einstelle, damit alles richtig tickt.... Viel Spaß noch! Eric

Hallo, Bertram Scharpf writes:

Hallo,

Danke nochmal für Eure Antworten. Jetzt hab's sogar ich verstanden. Ich fasse zusammen. (Wenn Fehler drin sind, verbessere man mich.) [...]

Gute Zusammenfassung, nachfolgend noch einige kleine Korrekturen.

II. Systemuhr

Die Genauigkeit dieser Quarzuhr ist vergleichsweise schlecht gegenüber der des Prozessors.

Nicht der Prozessor, der Betriebssystem-Kern errechnet, mit Hilfe des Prozessors, eine Systemzeit auf 6 Stellen nach dem Komma. [...]

Bei der Kommunikation im Netz können somit zwei Zeitpunkte in Stuttgart und in Sydney verglichen werden. Die zusätzliche Information ist die _Abweichung in Stunden_ von der Zeit auf dem nullten Längengrad: der "Greenwich Mean Time" (GMT), unter Unix genannt: "Universial Time Coordinated" (UTC).

Diese Aussage stimmt nicht ganz. GMT gibt es nicht mehr, da die Zeit nicht mehr als Mittelwert der Zeitangabe von mehreren Chronometern definiert wird, sondern durch die Zerfallszeit des Cäsiums. UTC ist die einheitliche Bezeichnung für die Weltzeit, das hat nichts mit Unix zu tun. Überall wo Zeit gemessen und benutzt wird, ist die Basis UTC, z.B. in der Navigation, bei der Fahrplanerstellung usw. [...]

Die Physikalisch-Technische Bundesanstalt in Braunschweig betreibt eine Cäsium-Uhr. Deren Zeit strahlt sie aus z. B. als Funksignal, das von den inzwischen sehr verbreiteten Funkuhren empfangen wird. Außerdem verschickt die Anstalt das Zeitsignal im Netz. Von Linux wird das gelesen mit

# netdate tcp ptbtime1.ptb.de ptbtime2.ptb.de

Es gibt auch noch andere Netzadressen mit Zeitservern, diese sind geordnet nach Stratum (eine Hierarchie der Zeitserver, Abhängig von dern Zeitquelle) Als Programme zur Erfassung der Zeit und zur Steuerung des lokalen Rechners und des lokalen Netzes gibt es noch xntp und chrony. Für den lokalen Betrieb empfehle ich chrony, da dies für Dial on Demand Systeme optimiert ist, im Gegensatz zu xntp, das eine ständige Netzverbindung verlangt. [...]

Wer ISDN hat, ist vielleicht schon einmal auf den Gedanken gekommen, seine Uhr nach der dort übertragenen Zeit zu stellen. Das geht auch. Aber: die ISDN-Zeit kann in der Genauigkeit mit der aus Braunschweig nicht mithalten.

Das würde ich sogar noch härter formulieren. Die ISDN-Zeit weicht häufig um etliche Sekunden von UTC ab, dies kannn sogar bis zu einigen Minuten gehen. [...] -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour

Hallo Bernd, * Am 13.04.2002 um 14:36 Uhr schrieb Bernd Brodesser:

Mit der Genauigkeit der Braunschweiger Atomuhr kann so wie so nichts mithalten, ganz einfach weil die Zeit der Braunschweiger Atomuhr per Gesetz die in Deutschland gültige Zeit ist.

dann wollen wir hoffen das da nicht eines Tages mal so ein Witzbold dran rumspielt ;-) Nach den Worten von Paulchen Panter: "Wer hat an der Uhr gedreht, ist es wirklich schon so spät..." SCNR -Jürgen -- Die Natur ergreift immer die Partie des versteckten Fehlers. / Registered Linux-User #130804 http://counter.li.org \ \ Linux Stammtisch Bremerhaven http://linux.hs-bremerhaven.de /

* Bertram Scharpf schrieb am 12.Apr.2002:

In der Datei `/etc/adjtime' steht vor dem Herunterfahren in der letzten Zeile: "UTC". Nach dem Neustart steht da: "LOCAL". Klar, daß dann die Uhr 2 Stunden nachgeht.

/etc/adjtime löschen, es wird neu angelegt. Bernd -- Umsteiger von Microsoft Windows xx? Hast Du schon file://usr/doc/howto/de/DE-DOS-nach-Linux-HOWTO.txt gelesen? Auch file://usr/doc/Books/Linuxhandbuch.dvi ist zu empfehlen. |Zufallssignatur 1

* Bertram Scharpf schrieb am 12.Apr.2002:

Am Freitag, 12. April 2002 00:47 schrieb eric berthold:

...

ich habe mal eine Grundlegende Frage zum Thema Uhrzeit:

...

Mails, die über den Server verschickt werden, tragen die richtige Uhrzeit. Aber wenn ich z.B. eine Datei per FTP hochlade, dann hat die ne andere Uhrzeit. Die liegt dann 2 Stunden zurück.

Wäre es nicht >zeit<, die Uhrproblematik einmal umfassend zu dokumentieren? Es gibt drei Uhren: die Hardware-Clock, die Systemzeit und den Fremden im Netz. Jeder hat eine Zeitangabe und eine Zeitzone. Die Übergabeformalitäten stecken in Optionen wie '-u' (`hwclock').

Nun auf dem Rechner gibt es erst einmal zwei Uhren, da ist zum einen die Hardwareuhr. Diese Uhr ist eine reale Uhr, die es irgendwo im Rechner gibt. Sie hat eine eigene kleine Batterie und läuft auch weiter, wenn der Rechner ausgeschaltet ist, sogar wenn er monatelang irgendwo vergammelt ohne am Stromnetz angeschlossen zu sein. Diese Uhr ist die, die Du im BIOS einstellen kanst, und die auch Windows verwendet. Allerdings ist sie nicht sonderlich genau. Linux verwendet daher eine Systemuhr, die softwaremäßig simmuliert wird und letztendlich vom Systemtakt gesteuert wird. (Clockinterupt) Beim Systemstart wird die Systemuhr nach der Hardwareuhr gestellt. Dabei wird eine Gangungenauigkeit der Hardwareuhr berücksichtigt. Das geschieht über die Datei /etc/adjtime Daher ist es wichtig, daß man diese Datei löscht, falls man die Hardwareuhr verstellt hat, und diese Verstellung nichts mit der Gangungenauigkeit zu tun hat. Bei UNIX ist es üblich, daß die Uhren in Weltzeit laufen nicht in Lokalzeit. Dies erleichtert einiges erheblich. Leider ist es bei Windows üblich, daß die Uhren in Localzeit laufen. Typisch Standalone Rechner, dafür ist das in Ordnung, nicht aber in einem Netzwerk. Bei UNIX werden die Zeiten der Dateien intern in Sekunden seit 1.1.1970 0:00 GMT gespeichert. Die jeweilig gültige Lokalzeit wird bei der Anzeige berechnet. Die Weltzeit kennt keine Sommerzeit, sie läuft kontinuierlich durch. Wenn die Uhrzeit auf Lokalzeit gesetzt ist, dann weiß Linux doch nicht, ist damit Sommerzeit oder Normalzeit gemeint. Woher soll Linux wissen, ob Windows schon umgestellt hat, oder nicht? Wenn es auf GMT eingestellt ist, dann gibt es keine Probleme, allerdings zeigt Windows dann die Zeit an, falls man auch schon mal Windows bootet. Wenn einem die Zeit bei Windows wichtig ist, sollte man localzeit einstellen, wenn es einem aber egal ist, oder gar kein Windows auf dem Rechner hat, dann sollte man auf jeden Fall GMT nehmen.

Im Header Deiner Mail steht

Date: Fri, 12 Apr 2002 00:47:08 +0200

(Da tauchen die zwei Stunden auf.) Vielleicht haben die Amis

Ja, das ist die Zonenzeit, die in Deutschland im Sommer gültig ist. Weltzeit plus zwei Stunden. Im Winter ist es eine Stunde.

das irgendwo dokumentiert, denn die leben in sechs Zeitzonen.

Und unterschiedliche Sommerzeitreglungen in einzelne Staaten. Bernd -- LILO funktioniert nicht? Hast Du /etc/lilo.conf verändert und vergessen, lilo aufzurufen? Ist Deine /boot-Partition unter der 1024 Zylindergrenze? Bei anderen LILO Problemen mal in der SDB nachschauen: http://localhost/doc/sdb/de/html/rb_bootdisk.html |Zufallssignatur 6

Hallo, sto68@gmx.de writes:

Hi zusammen,

nach so viel Theorie hier noch ein kleines Problem aus der Praxis:

Bei mir hängt der Rechner beim Hochfahren etwa 90s mit der Meldung "Setting up the cmos clock" Das scheint mir nicht normal zu sein.

Was macht er so lange? (Ver)stellt er da die Uhr? Wer weiß was?

[...] Vielleicht ist deine Batterie leer und Linux kann die Uhr nicht auslesen? Oder der Real Clock Treiber ist ein unübliches Modell? Was sagt denn /var/log/boot.msg dazu? -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour