Zeitverschiebung zwischen Notes 4 und 6

Das Problem hatte ich bei einer R4->R5 Umstellung eines Kunden anfangs auch.

Ursache: R4 ist die letzte Version, die noch als 16-bit Version für das damalige Windows 3.x geschrieben wurde. Unter Windows 3.x hatte das Systemdatum noch kein "echtes" Sommerzeitflag und auch die Windows-Zeitzone war eher eine DOS-basierte Krücke. R4 war ein Multiplattformclient (OS/2, Mac, Win, Unix) und von daher mußte die Zeitzone stabil über alle Versionen sein auch wenn das Betriebssystem das nicht konnte. Das hatte den Effekt, das sowohl Notes als auch das System eine Zeitzoneneinstellung hatten. Änderte man im Notes die Zeitzone dann änderte Notes das für Windows mit. Genauso verhält es sich bei R4 mit der Sommerzeit. Diese ist wie eine zusätzliche Zeitzone.

Wenn man in Notes unter R4 die Sommerzeit aktivierte, wurde im Windows die Zeit vorgestellt. Hatte man die Sommerzeit aber zentral für alle User schon eingestellt wollten viele Firmen nicht dem jeweiligen Windows (und damit dem User) das überlassen sondern es wurden simpel alle Uhren zum Stichtag nach vorn gedreht (und im Winter retour). Das heißt, weder Notes noch Windows liefen wirklich auf Mitteleuropäischer Sommerzeit (CEDT) sondern weiterhin auf Mitteleuropäischer Zeit (CET).

Seit R5 (32bit und Windows 95 bis XP) gibt es die vielen Plattformen nicht mehr und die Betriebssystemhersteller haben auch dazugelernt, die 32bit-Systeme haben bei jeder Zeit auch die Zeitzone hinterlegt. Es ist jetzt also sinngemäß nicht simpel "16:51" sondern "16:51 CEDT".

So, wer bis hierher alles verstanden hat ahnt was kommt. Notes ist seit jeher international ausgelegt, d.h. wenn ich eine Einladung aus London bekomme, die ein Londoner angenommen für morgen 08:00 GMT vor Ort geplant hat, dann zeigt mein Client mir diese Zeit nicht als GMT im Kalender an sondern er zeigt es in meiner Zeitzone, aus 8:00 GMT wird 10:00 CEDT. Dazu steht in jedem Datumsfeld die Zeitzone. Angezeigt wird diese Zeitzone jedoch nur, wenn sich die ursprüngliche unterscheidet.

Da eure R4-Clients anscheinend mit CET gearbeitet haben, eure jetzigen Windowsxxx aber CEDT aktiv haben erkennt Notes das und rechnet für die Bildschirmanzeige alle Zeiten um. Das ist per Design so gewollt und nicht abstellbar. Genaugenommen die Strafe dafür daß man unter R4 die Zeitzonen falsch hatte

Wie kommt man aus dem Dilemma?

Nicht so einfach. Problem ist nämlich, daß man jetzt nicht simpel alle Zeiten per Agent -1 oder +1 machen kann oder die Zeitzone pro Feld ändert. Vielmehr ist ja seit der Umstellung schon gearbeitet worden und damit existieren jetzt korrekte (die nach der Umstellung) und falsche Zeiten (aus R4). Ich habe für den damaligen Kunden einen relativ aufwendigen Agenten geschrieben, der anhand bestimmter Kriterien die falschen von den echten Zeiten herausgesucht und in den Kalendern korrigiert hat. Das Programmieren und Testen hatte etliche Tücken ... aber last but not least haben wirs geschafft. Ich habe damals sehr viel über bestimmte Felder und Einstellungen und deren Zusammenspiel in Client/Server/Betriebssystem gelernt.

Also für die Umstellung 4->6 muß der Client auf MESZ (CEDT) gebracht werden, also der Sommerzeithaken (und damit verbunden NOTES.INI und korrekte Windowszeitzone). Danach sind alle Einträge auf Zeitzone zu prüfen und alles was im Kalender an Einträgen zwischen dem 1. und letzten Tag der Sommerzeit liegt muß per Script auf MESZ gebracht werden. Dabei ist die Verschiebung der Einträge zu beachten die im gleichen Script zu erfolgen hat.

Wenn alle Einträge korrekt mit MEZ (CET) und MESZ (CEDT) versehen sind kann die eigentliche Umstellung reibungslos erfolgen (sofern auch das Windows beim Nutzer die Sommerzeit aktiv hat).

Zur DER Frage ;=) Der Agent besteht aus 2 Teilen, nämlich ein Teil vor und ein Teil nach der Umstellung. Zu dem Agenten gehören mehrere Protokolldatenbanken und Mails in denen der User auf Knöpfchen drücken muß (da die Umstellung mit seiner ID auf dessen Client läuft zu einem Zeitpunkt der dem User paßt). In den Scripten sind noch viel mehr Dinge drin als du brauchst, da mein Kunde zeitgleich eine Migration seiner Mitarbeiter auf einen anderen Certifier in einer neuen Domäne wünschte und gleichzeitig auf die alten Server noch für Altanwendungen weiter zugegriffen werden mußte. Da gabs mit Verschlüsselung, Signaturen und Berechtigungen einiges anzupassen. Insofern ist das ganze so für dich nicht verwendbar. Dazu kommt, daß der Kunde die gesamte Programmierung und Migration bezahlt hat und das Ergebnis sein geistiges Eigentum ist das ich damit nicht weitergeben darf und werde selbst wenn die Sachen nach 2 Jahren die das her ist noch in irgendeiner Form vorhanden sein sollten (sorry aber so sind die Regeln).

Hallo phops, es wäre nicht nötig jedesmal den Haken zu setzen wenn zwischen Sommer und Winterzeit gewechselt wird. Ihr hättet ihn nur einmal einschalten müssen zu Beginn, da Deutschland ein Land ist was Sommerzeit berücksichtigt. Das wäre die richtige Konfiguration gewesen.
Gruß
Harry

Hallo zusammen,

ein ähnliches Problem wie oben beschrieben habe ich auch!
Allerdings ist es keine laufende Umstellung sondern eine feste Konfiguration, die länger so bestehen bleiben soll:

ich habe 2 Geschäftsstellen angebunden und alle benutzen Lotus Notes. Hierbei folgende Konfiguration:
Alles (Server und Clients) laufen noch unter OS/2. Jede Geschäftsstelle hat einen eigenen LN - Server, der sich mit dem in der Hauptstelle abgleicht.
Die Server sind auf LN 5 Basis und die Clients LN 4.5.

(Ich habe einen W2K Rechner, der dann als Admin-Client für LN genutzt wird, da auf den Servern keine Client-Software installiert ist.)

Nun habe ich eine Mail-Probe gemacht und die Mitarbeiter angewiesen mir auf einen externen 1und1-Account je eine E-Mail zu schicken, da intern Zeitprobleme bestehen.

Hier das Ergebnis:

E-Mails aus der Hauptstelle: Die Zeit stimmt, bei den Clients ist in LN MEZ mit Sommerzeit angehakt eingestellt.

E-Mails aus der Geschäftsstelle: Die Zeit ist falsch, die schicken "aus der Zukunft" statt 12 Uhr steht dann bei deren Mails 13 Uhr drin. Ebenfalls in LN MEZ mit Haken bei Sommerzeit.

Nun zu den Fragen:
Wie kann ich das beheben?
Muss ich um das zu beheben bei den Server vor Ort was machen, oder kann ich auch über den benannten "Admin-Client" was machen?

Danke schon einmal im voraus!!!
MfG

---EDIT-----
noch ein zusatz:
woher zieht sich denn nun der R5 seine Zeit?
Weil er ist ja immer noch auf OS/2 installiert----kann es daran liegen?

Vielleicht helfen dir ein paar Ergänzungen zu meinen vorherigen Ausführungen (die natürlich auch für deine Umgebung gelten):

- Ab R5 erhalten Server (und Clients) die Zeit ausschließlich vom Betriebssystem. Man kann hier zwar für die Zeitdarstellung mit INI-Parametern tricksen aber das ändert nichts an der Zeitzone.

- Bis R4 werden Zeitzonen ausschließlich im Notes selbst verwaltet, d.h. die Clientuhrzeit wird immer in der aus dem Betriebssystem gelesen, die dazugehörende Zone vom Notes aus dessen Konfiguration hinzugefügt.

- Alle Releases: Bekommen Client oder Server Datums- oder Zeitfelder irgendwoher werden sie auf die in der jeweiligen Konfiguration festgelegten Zeitzone on-the-fly umgerechnet. D.h. man sieht immer alles in der Zeitzone, die beim Client oder Server eingestellt (oder aus dem Betriebssystem ermittelt) wurde.

- Alle Releases: Schreibt man eine Mail "online" (also z.B. indem man die auf dem Server liegende Mail-DB öffnet) so wird immer die Serverzeit dabei verwendet. Schreibt man eine Mail "offline" (mit der lokalen Replik im Insel-Modus z.B.) so wird die Clientzeit verwendet.

Aus dem Genannten läßt sich also folgendes herleiten: Um den Verursacher einer falschen Zeitzone zu ermitteln nimmt man sich einen R4-Client und schreibt jeweils eine Mail "online" und eine Mail "offline" die man anschließend vergleicht. Damit dürfte der Schuldige gefunden sein. Ich persönlich tippe hier auf den Server der Geschäftsstelle.

Hi Carsten,

danke für deine Ausführungen, hat mir einiges klargemacht.
Der heutige Stand ist folgender:

.Memo "verbindungslos" verschickt.
In diesem Falle kam die Mail zweimal an:
einmal mit der richtigen und einmal mit der falschen Zeit (+1 Stunde). Leider weiß ich nicht ob die Mail auch mit einer Stunde Verzögerung zum zweiten mal ankam.

Kannst du dir da einen Reim drauf machen?

.Bei dem GeschäftsstellenServer die Zeit um eine Stunde zurückgestellt (statt 12 Uhr - 11 Uhr) und danach den Domino-Server neu gestartet:.
Dann passte es. Und diese E-Mail kam auch nur einmal an.

Leider kann keines von beidem die Lösung sein....denn auf dem Server laufen noch andere Anwendungen, die leider die "richtige Zeit" benötigen und das andere ist für unsere User leider zu kompliziert (und die Mail würde zweimal ankommen)....(*läster* die sind froh, wenn sie die "Enter"-Taste finden :lol: */läster*)

Aber einen Zusatz habe ich noch, denke aber, dass es nicht wichtig ist:
ALLE E-Mails (d.h. die der Hauptstelle mit richtiger Mailzeit, als auch die aller Geschäftsstellen mit der falschen Mailzeit) laufen über einen Kom-Server, der ist unter OS/2 installiert und der hat noch LN 4.5 im Einsatz. Aber wenn ich dich richtig verstanden habe fügen die Server, bei denen die E-Mail nur "weitergeleitet" wird keine weiteren Informationen mehr hinzu, sondern nur die Server/Clients, auf deren Replik die Mail erstellt/bearbeitet wurde, oder?!

Beim Testen ist mir noch etwas aufgefallen: Ich habe bei einem OS/2 Client mit Lotus Notes 4.5 den Haken bei der Sommerzeit rausgenommen. Da hat sich die Uhr erst um eine Stunde zurückgestellt, aber nach kurzer Zeit (<5 Minuten) stand die Zeit wieder auf dem alten Stand, obwohl der Haken immer noch raus war! Warum ist das so?

Danke schon einmal für eine Antwort!

MfG
Daniela

Zitat

Memo "verbindungslos" verschickt - kommt 2x an

Also das Problem würde ich mal genauer untersuchen, eine Mail kann nur 1x ankommen ansonsten muß sie ja an irgendeiner Stelle durch falsche Konfiguration verdoppelt werden. Unbedingt suchen das Problem. Da die Mail 2x ankam wissen wir immer noch nicht genau ob der Client das Problem ist...

Weg einer Offline Mail:

- "Senden" speichert Mail in der lokalen mail.box am Client
- "Online" gehen überträgt diese 1 Mail in die mail.box des Servers der in der Arbeitsumgebung eingetragen ist.
- Weiterer Versand analog "Online" erstellter Mails

Aber um das Problem nochmals etwas allgemeiner anzugehen:

Jedes Datum/Zeitfeld wird immer im GMT Format gespeichert. Erst der Client bzw. Server berechnet für die Anzeige wieder die Differenz und dabei ist es natürlich von Bedeutung ob und wie der Client die Zeit berechnet.

Beispiel:

Angenommen ich trage einen Kalendertermin für heute 10:00h Vormittag ein dann rechnet mein Client das (unsichtbar für mich) in GMT um und schreibt was in die DB? In Berlin herrscht MEZ also GMT+1, aber stopp, es ist ja Sommerzeit, also GMT+2. Damit wird in die DB geschrieben 8:00h. Egal was jetzt mit dem Dokument passiert, öffnet ein anderer Client diesen Eintrag sieht er entweder 9:00h (GMT+1 wenn am Client MEZ eingestellt wurde) oder 10:00 (GMT+2 wenn am Client MESZ eingestellt wurde).

Wichtig ist also nicht alleine die Uhrzeit sondern die Uhrzeit und die richtige Zeitzone!

Bis Notes 4 war ausschließlich in der Arbeitsumgebung die Zeitzone entscheidend, da damals die Betriebssysteme noch nicht mit Zeitzonen umgehen konnten (ja Windows 3.x hat zwar Sommer/Winterzeit umgestellt aber nur simpel durch addieren 1 Stunde). Viele Admins haben graue Haare bekommen wenn sie zentral am Server die Zeit zum Sommeranfang vorstellten und allen Clients die Net Time verteilten und das Windows auf diese Zeit dann nochmal eine Stunde draufpackte...Im Endeffekt haben deshalb viele die Zeitzonen und Sommerzeiteinstellungen simpel deaktiviert...fataler Fehler mit Folgen wie das obige Rechenbeispiel zeigt.

Ab Notes 5 zieht sich der Client die Zeit ausschließlich aus dem Betriebssystem. Bei Windows kein Problem, da seit 95 alle Windowsvarianten mit Zeitzonen umgehen können. Notes weiß daher auch genau ob es aus der im Beispiel genannten 8:00h 1h oder 2h addieren muß.

Dumm nur, wenn das Betriebssystem keine Zeitzonen beherrscht oder aber der Client/Server diese nicht auslesen kann weil sie nur propietär in irgendwelchen Environments wenn überhaupt stiefmütterlich gepflegt sind.

In diesem Fall muß dem 5er Client oder Server mitgeteilt werden daß er NICHT das Betriebssystem fragen kann sondern ihm die Zone fest vorgeben. Zusätzlich muß ich (im Falle von Sommerzeit) dem 5er Client/Server sagen an welchem Datum er wieder von MESZ auf MEZ schalten muß. Parallel müssen natürlich die Uhrzeiten auch passend zur Zone eingestellt sein ;=)

Wenn also OS2 die Zeitzone nicht korrekt verwaltet müssen folgende NOTES.INI Variablen gesetzt werden:

TimeZone=1 (1 entspricht GMT+1 und damit MEZ für Deutschland)
DST=1 (1 = ja, damit wird während der Sommerzeitperiode automatisch aus MEZ die Zone MESZ, also GMT+2)
DSTlaw=begin_month begin_week begin_day end_month end_week end_day (von wann bis wann gilt DST in relativer Form)

Für DSTlaw gibts alternativ auch Start- und Endvariablen, die aber offiziell nicht mehr unterstützt werden.

Der Vollständigkeit halber sei noch erwähnt, daß eine Variable existiert die unter R5 die Verbindung Noteszeit - Betriebssystemzeit + Zone trennt (wenn man z.B. einen R5 Server unter Windows eine andere Zone geben möchte als sie im Windows selbst eingestellt wurde)

UseNotesTimeZone=1 (deaktiviert die Betriebssystemzeitzone im Notes).

Zitat

Beim Testen ist mir noch etwas aufgefallen: Ich habe bei einem OS/2 Client mit Lotus Notes 4.5 den Haken bei der Sommerzeit rausgenommen. Da hat sich die Uhr erst um eine Stunde zurückgestellt, aber nach kurzer Zeit (<5 Minuten) stand die Zeit wieder auf dem alten Stand, obwohl der Haken immer noch raus war! Warum ist das so?

Wie bereits weiter oben erwähnt wird von den meisten Admins die Zeit für alle Clients zentral vorgegeben (NET TIME). Das geschieht entweder durch Loginscripts auf Fileservern oder indem am Client ein lokales Tool (Dienst) läuft.

Änderst du am R4 Client nun die Zeit indem du den Sommerzeithaken entfernst dann schaltest du damit von MESZ (GMT+2) auf MEZ (GMT+1) um, daher wird die Uhr um eine Stunde zurückgestellt, nehmen wir an von 10h auf 9h.

Läuft jetzt auf diesem PC ein Tool zum regelmäßigen Zeitabgleich dann stellt dieses natürlich die Zeit wieder um eine Stunde vor, weil es ja eigentlich 10h ist, aus 9h wird wieder 10h - aber: jetzt ist die Zeitzone MEZ (da ja nur die Zeit aber nicht die Zone verstellt wurde!) Und schon habe ich einen Client produziert der eine Zeitdifferenz von 1h zu allen anderen (mit Haken = MESZ)hat...