Autor Thema: Wie Datum richtig speichern? DateNumber geht nicht aber NDT-Klasse  (Gelesen 3364 mal)

Offline khing

  • Aktives Mitglied
  • ***
  • Beiträge: 115
  • Geschlecht: Männlich
Hallo,

ich bin gestern beim Programmieren mal wieder über eine Hürde mit Datumsoperationen gestolpert. Um die NotesDateTime Klasse aus Performance-Gründen zu umgehen, habe ich mir eine Adjust-Funktion von Tagen mit Datenumber gebaut. Also ungefähr so:
Code
Public Function AdjustDays(StartDate as Variant, Days2Add as Integer)
      AdjustDays = CDat(DateNumber(Year(StartDate),Month(StartDate),Day(StartDate) + Days2Add ) + TimeNumber(Hour(StartDate), Minute(StartDate), Second(StartDate)))
End Function
Bitte nicht wegen dem Programmierstiel schimpfen - sieht in Wirklichkeit natürlich viel besser aus  ;)

Nun entsteht das eigentliche Problem, wenn ich diesen Rückgabewert auf ein NotesItem vom Typ Datum speichere. Dabei wird anscheinend ein String gespeichert aber laut Dokumenteigenschaften ist es weiterhin ein Datum (auch in der Form DD.MM.YYYY HH:MM:SS). Nimmt man diesen Wert nun für Vergleichsoperationen heran, geht garnichts mehr. Die Ergebnisse sind alle falsch. Mit dem Adjust der NDT-Klasse klappt natürlich alles ohne Probleme...  ???

Wie kann ich also eine Konvertierung dieses "STRING" oder was auch immer, wieder auf ein Datum/Zeit-Wert bekommen? Habt ihr da Lösungen?

Gruß Kristian

"Notes kann alles außer Kaffee kochen!"

Offline koehlerbv

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 20.460
  • Geschlecht: Männlich
Irgendwie fehlt mir an dem Codeschnipsel das entscheidende Stück: Was ist der Rückgabewert der Function??

Das Prinzip ist ansonsten richtig. Das Cdat innerhalb der Function ist allerdings gaga ("weisser Schimmel").

Bernhard

Glombi

  • Gast
Warum sollte NotesDateTime performancekritisch sein  ???
Damit kann man alle möglichen Dinge mit Datums-/Zeitwerten treiben.

Andreas
P.S.: Soll ich noch ne Umfrage machen?  ;D

Offline khing

  • Aktives Mitglied
  • ***
  • Beiträge: 115
  • Geschlecht: Männlich
@Bernhard: Oja das kommt davon, wenn man OnTheFly hier Code eingibt  ;D Das ist natürlich Variant
Code
Public Function AdjustDays(StartDate as Variant, Days2Add as Integer) as Variant
      AdjustDays = CDat(DateNumber(Year(StartDate),Month(StartDate),Day(StartDate) + Days2Add ) + TimeNumber(Hour(StartDate), Minute(StartDate), Second(StartDate)))
End Function

@Andreas: Der Beiweis wurde hier http://www.jnotes.de/jnotes/JRIK-8J5RZS erbracht. Im "kleinen" Umfang natürlich kein großer Unterschied aber bei einigen Tausend Dokumente ist es auf jeden Fall spürbar.
"Notes kann alles außer Kaffee kochen!"

Offline koehlerbv

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 20.460
  • Geschlecht: Männlich
An Deiner Function liegt das schon mal nicht - die liefert brav und wie erwartbar ein Variant vom Typ 7 zurück. Packst Du das in ein NotesItem (egal, ob das Item auch in einem Feld einer Maske verwendet wird oder nicht), so wird auch das Item vom Type Time/Date sein.
Du musst Deinen "Fehler" also ausserhalb Deiner Function suchen.

Bernhard

Offline khing

  • Aktives Mitglied
  • ***
  • Beiträge: 115
  • Geschlecht: Männlich
Jetzt habe ich mir noch einmal die Datentypen in den Dokumenteneigenschaften angesehen und da sehe ich, dass bei einem funtkionstüchtigen Wert "Zeit/Datum-Liste oder Zeitraum" steht und wenn es nicht geht, dann "Zeit/Datum" (Rückgabewert aus der Funktion). Außerdem ist der Wert mit "DD.MM.YYYY HH:MM:SS CET" aufgebaut, wenn es klappt und der falsche mit "DD.MM.YYYY HH:MM:SS CEDT". Kann es das sein? Auf jeden Fall schreibe ich auch ein Datatype 7 in das Backend-Doc.
"Notes kann alles außer Kaffee kochen!"

Offline diali

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 1.023
  • Geschlecht: Männlich
so einfach geht es bei Zeitzonen nicht.

Wahrscheinlich verschiebst du das Datum von Sommerzeit auf ein Datum in der Winterzeit (oder umgekehrt). Die Differenz ist dann nach dem Verschieben des Datums genau eine Stunde, da der Notes-Client deine lokalen Zeiteinstellungen mit beachtet.

Nun zu den schlechten Nachrichten,
1. in der Klasse NotesDateTime ist TimeZone, ZoneTime Read-Only!
2. ConvertToZone, konvertiert in eine andere Zeitzone, dies wird dir im Client auch mit dieser Zeitzone angezeigt

Lösung:
1. ermitteln, welche Zeitzone im Ausgangsdatum verwendet wurde
2. prüfen ob das Zieldatum in der gleichen Zeitzone ist
3. Zeitzonen stimmen überein => alles i.O.
4. Zeitzonen stimmen nicht überein, dann muss die Zeit mit AdjustHour (in einigen Ländern auch mit AdjustMinute - bei Verschiebungen, die keine vollen Stunden sind) angepasst werden.
Gruß
Dirk

Glombi

  • Gast
@Bernhard: Oja das kommt davon, wenn man OnTheFly hier Code eingibt  ;D Das ist natürlich Variant
Code
Public Function AdjustDays(StartDate as Variant, Days2Add as Integer) as Variant
      AdjustDays = CDat(DateNumber(Year(StartDate),Month(StartDate),Day(StartDate) + Days2Add ) + TimeNumber(Hour(StartDate), Minute(StartDate), Second(StartDate)))
End Function

@Andreas: Der Beiweis wurde hier http://www.jnotes.de/jnotes/JRIK-8J5RZS erbracht. Im "kleinen" Umfang natürlich kein großer Unterschied aber bei einigen Tausend Dokumente ist es auf jeden Fall spürbar.

Der Link ist gut und da wird auch der Vorteil von NotesDateTime sichtbar:
Weil das NotesDateTime-Objekt intern alle Datums- und Zeitangaben auf UTC umrechnet

Das mit dem Performancenachteil, wenn sowas auf sehr viele Dokumente angewendet wird, erscheint plausibel. Das wäre dann in einem solchen Fall zu prüfen.

Anfreas

Offline khing

  • Aktives Mitglied
  • ***
  • Beiträge: 115
  • Geschlecht: Männlich
So, habe den Fehler gefunden! Es war ein Fehler in der Berechnung von meiner eigentlichen Funktion. Das Jahr war nicht 2014, sondern 2114  :o :o :o - Das muss man erstmal im dem Zahlenchaos finden  ::)
Irgendwie hatte ich am Anfang die Werte negiert mit "Wert* -1" und da kam dann sehr viel komische Sachen raus. Habt vielen Dank für eure Hilfe.
"Notes kann alles außer Kaffee kochen!"

 

Impressum Atnotes.de  -  Powered by Syslords Solutions  -  Datenschutz