Das Notes Forum
Domino 9 und frühere Versionen => Entwicklung => Thema gestartet von: held05 am 30.03.05 - 15:15:27
-
Hallo zusammen,
bin verzweifelt auf der Suche nach einem Agenten der mir alte Kalendereinträge die vor der Umstellung der Sommerzeit gemacht wurden korrigiert, da ich unseren Anwendern nicht zumuten kann das Sie Ihre unzähligen Kalendereinträge neu erstellen bzw. korrigieren müssen.
Es sei angemerkt, dass die notes.ini alle Einträge enthält die für die Zeitumstellung notwendig sind. (Timezone=-1,
DST=0, ...)
Gruss
Held05
-
... vielleicht sitze ich auch auf meiner Leitung - wo liegt dein Problem - sollen die Termine um eine Stunde verschoben werden?
ata
-
Es sei angemerkt, dass die notes.ini alle Einträge enthält die für die Zeitumstellung notwendig sind. (Timezone=-1,
DST=0, ...)
Äh, DST=0 - genau das verhindert doch eine automatische Umstellung bzw. Berücksichtigung der Sommerzeit. Und dann brauchst Du tatsächlich einen Agenten, der nicht die Zeiten verändert, sondern für die Berücksichtigung Sommer-/Winterzeit umstellt.
Sag' mal bitte genaueres.
Bernhard
-
Das Problem ist folgendes: Seither wurde in unserem Notes-Umfeld eingerichtet, dass die Sommerzeit hier nicht gilt. Wir wollen dies aber jetzt umstellen, nur wenn wir das machen, werden Kalendereinträge die vor der Zeitumstellung erstellt wurden in den Kalendern um eine Stunde verstellt. Diese Kalendereinträge wollte ich evtl. durch einen Agenten korrigieren lassen.
-
Eine solche "Korrektur" bringt gewöhnlich einen ganzen Sack voll Flöhe (sprich Probleme) mit sich. Ich würde das nicht ohne sehr kompetente Hilfe durchführen (selbst ich würde mich davor hüten, es selber zu machen ....). Einer der ganz wenigen Fachleute mit einschlägiger Erfahrung ist Daniel Nashed: http://www.nashcom.de
-
... dem kann ich mich nur anschließen - leg dir eine Testumgebung mit Produktivdaten an - das kann auch nach hinten los gehen...
ata
-
Verspätet, weil ich jetzt drei Tage im "Internet-Exil" war:
Anton's Hinweis MUSS auf jeden Fall beachtet werden - keine derartigen Stunts in einer Produktivumgebung. NIEMALS.
Wenn das steht, ist es nicht umbedingt ein Hexenwerk, Korrekturen via Agent zu bewerkstelligen. NotesDateTime values beinhalten auch die Informationen, ob DST berücksichtigt werden muss - siehe hierzu die NotesDateTime class property "IsDST". Du kannst allerdings auch jedem NotesDateTime object zwangsweise DST "drüberbügeln" mit der Methode "ConvertToZone", wenn Du nur in einer einzigen time zone arbeitest.
Wie gesagt: Es ist kein Hexenwerk, aber Tests bitte nicht mit irgendwelchen produktiven Umgebungen durchführen.
Für weitergehende Unterstützung stehe ich gerne bereit.
Bernhard
-
Für weitergehende Unterstützung stehe ich gerne bereit.
Bernhard
Da ich vor dem gleichen Problem stehe und held05 das Thema leider nicht weitergeführt hat, bitte ich mal um Unterstützung.
Die Designer-Hilfe konnte mir unter "IsDST" und "ConvertToZone" nicht wirklich weiterhelfen, was aber wahrscheinlich an den nicht vorhandenen LS-Kenntnissen liegt.
Alle Mitarbeiter arbeiten dauerhaft in der gleichen Timezone und eine Testumgebung ist auch vorhanden. Was jetzt noch fehlt ist das Script.
Um genau da ist meine Bitte um Unterstützung - kannst Du hier evtl. einen Script-Entwurf einstellen?? Da ich wie gesagt LS nicht beherrsche, kann ich nicht mal eine Vorlage bieten aber da dies auch in diesem Forum ein jährlich wiederkehrendes Problem ist - könnte vielleicht auch der ein oder andere hier noch davon profitieren.
Danke
-
Das Problem ist etwas umfangreicher, als Du vielleicht denkst, Dynamix. DT-Items gibt es ja nicht nur in der Mail-DB, sondern in der Regel noch viel zahlreicher in anderen DBs.
Gerade bei dieser Problematik gibt es keine allgemeingültige Lösung (oder doch - ein Tool, die durch alle DBs geht und in den DBs in jedem Dokument jedes Item prüft - und das ist garantiert nicht freeware. Über das Produkt sollte ich aber vielleicht mal nachdenken ;D).
Das Dealen mit DT-Werten in Notes (wie auch in etlichen anderen Apps, die Zeitzonen und DST beherrschen) ist nicht trivial. In diesem Fall ist das Beherrschen (!) von LS eine Grundvoraussetzung. Fertigen Code kann ich daher einfach nicht bieten.
Bernhard
-
OK - da hatte ich deinen Betrag doch etwas falsch verstanden. Somit bleibt dem Nutzer also nur "Handarbeit" bei der Terminberichtigung.
Trotzdem nochmals Danke für die schnelle Antwort.
-
Somit bleibt dem Nutzer also nur "Handarbeit" bei der Terminberichtigung.
Nein, das stimmt so nicht. Aber mit LS muss man sich als Verantwortlicher dann auskennen, um alle Mail-Files umzustellen. Nimm' es mir bitte nicht übel, aber ich liefere keinen Code für jemanden, der nicht - und sei es über eine Testumgebung, aber vor allem auch mit eigenem Know-How - die Verantwortung dafür selber übernehmen kann (hier: Mit fundiertem LS-Know-How).
Gegen einen entsprechenden Beitrag zur Ernährung meiner Familie, meiner Infrastruktur etc. übernehme ich die Aufgabe natürlich gerne mit voller und eigener Verantwortung ;D
Bernhard
-
Hallo Dynamix,
schade dass man deinen Namen nicht kennt. Bernhard hat schon recht, wenn er das nicht für lau macht.
Ich hab eine solche Korrektur schon einige mal in Banken umgesetzt, waren oft verteilt auf >15 Server manchmal bis zu 700 Datenbanken. Den verwendeten Code werde ich aber so auch nicht bereitstellen!
Du musst dann jedes DT-Feld prüfen, evtl. korrigieren, die Zeiteinstellung in der AU korrigieren. Zusätzlich damit rechnen, dass der Looser die akribisch vorbereitete SF nur einmal anklickt, die Umstellung auf der anderen Lokation nicht umsetzt. Die Termine im Kalender sind aber bereits umgerechnet, also Flag setzen um erneute Umrechnung zu verhindern, lediglich die AU ist nicht geändert, muss jetzt passieren. Du musst beim zweiten/dritten/... Anklicken ein Umrechnen der Termine unterbinden, aber trotzdem die AU evtl. korrigieren, etc.
Ist wirklich nicht ganz trivial. Ohne Script-Kenntnisse eigentlich Selbstmord: Stell dir mal das Chaos vor, wenn was schiefgeht, was soll man denn da zurücksichern ?! Die Chefs kommen nach Belieben zu Besprechungen und Terminen und du bist schuld !
Da musst du einen finden, der das verantwortlich übernimmt, umsetzt und eventuelle Probleme auch im Nachgang (!) noch korrigieren kann. Aber das gibts nicht für @Null, das solltest du dir schon was kosten lassen.
Jo
-
Hy Lotusprofis,
ich habe ein Problem, muß in einer 5er Umgebung Kalendereinträge durchscannen und auf Winter/Sommerzeit umstellen. Scriptseitig eigentlich kein Problem nur wie bekomme ich raus wann die Sommerzeit startet bzw. endet??? Ist ja nicht an ein Datum gebunden. Gerade Jahrestage über 10 oder 20 Jahre stellen mein Problem dar.
Danke für die Hilfe.
Gruß Alex
-
1) Neues Thema, neuer Thread. BITTE!
2) Ein Jahrestag hat, wie der Name schon sagt, keine Uhrzeit, da es ein Tag und kein Termin ist. Bei der Uhrzeit, zu der man an dem Jahrestag erinnert werden soll, würde ich nicht mehr als x Jahre in die Zukunft gehen, da die SZ/WZ Umstellungstermine immer nur für ein paar Jahre im Voraus definiert werden IIRC.
Richtlinie 2000/84/EG (http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32000L0084:DE:HTML) des Europäischen Parlaments und des Rates vom 19. Januar 2001 zur Regelung der Sommerzeit :
Artikel 1
"Sommerzeit" im Sinne dieser Richtlinie ist die Zeit des Jahres, in der die Uhr gegenüber der Uhrzeit während der übrigen Zeit des Jahres um 60 Minuten vorgestellt wird.
Artikel 2
Ab dem Jahr 2002 beginnt die Sommerzeit in jedem Mitgliedstaat am letzten Sonntag im März um 1 Uhr morgens Weltzeit (http://www.cl.cam.ac.uk/~mgk25/time/zeitgesetz.de.html).
Artikel 3
Ab dem Jahr 2002 endet die Sommerzeit in jedem Mitgliedstaat am letzten Sonntag im Oktober um 1 Uhr morgens Weltzeit.
-
Danke, werde ein neues Thema erstellen.
-
Hier http://atnotes.de/index.php?topic=39934.0 (http://atnotes.de/index.php?topic=39934.0) geht's weiter.
Axel