Datum und Zeitbrechnung

[andrew22]

hi ho !

ich habe in einer Maske 4 Felder : Startdatum , Startzeit , Enddatum , Endzeit -> alles Notes Datumsfelder.

Dieser Werde werden in einem Agent eingelesen und zwar in einer jeweils dafür deklarierte Stringvariable.

Bsp : Dim startdatum As String
startdatum = doc.GetITem........

ich muss nun berechnen wieviel Stunden und Minuten zwischen Start und End Datum / Zeit sind

also Bsp :

05.05.2005 13:30:00 - 06.05.2005 19:45:00

Ich brauche nun die Dauer und zwar Stunde und Minute also sprich keine ahnung nur als Beispielen 25 Stunden und 30 min.

hab keine ahnung wie ich das am besten machen kann

hoffe auf hilfe

g8

[TMC]

Bsp : Dim startdatum As String

Deklariere das besser nicht als String, sondern als Variant.

Es gibt eine Date-Klasse in LS, aber oft braucht man die gar nicht.
Nimm einfache Operatoren (<, >, etc.).

Hier ist schonmal eine Liste von mir:
http://www.atnotes.de/index.php?topic=17738.0

Wenn Du noch Fragen hast, sag Bescheid 
Matthias

[koehlerbv]

Zwei Fragen:
Warum berechnest Du die Zeitdifferenz nicht gleich in der Maske ?
Steht in den Time-Felder wirklich nur ein Zeitwert oder auch dort ein Datums-/Zeitwert ?

Bernhard

[andrew22]

das sind Datumsfelder . Notes Datumsfelder wo man nur auf diese Kleine Uhr klickt.

also irgendwie weiss ich immer noch net wie ich das machen soll

[TMC]

Einfach die beiden Datumswerte (Variants, entspricht Date/Time wenn Du als Basis die ItemValues nimmst) voneinander abziehen.
Das Ergebnis entspricht Tage. Eine Stunde ist also 1/24.

[andrew22]

das heißt ich soll Enddatum - Startdatum rechnen

und Starttime und Endtime ist egal ?!?!?

[TMC]

Das kann jetzt unter Umständen gefährlich werden, weil in den Zeitfeldern ein Datum hinterlegt sein kann.

Am besten setzt Du Dir das Datum erstmal zusammen:
vStart = Fix(vStartDatum) + Fraction(vStartZeit).

Das gleiche mit dem Ende-Datum / Uhrzeit.

Die beiden Ergebnis-Variablen vergleichst Du dann:
vResult = vEnd - vStart

vResult kannst Du dann auswerten.

[koehlerbv]

Wichtig ist noch die Rundung, sonst kommt da leicht ein "unscharfer" Wert heraus:

Code

	Dim docCurrent As NotesDocument
	Dim vStartDT As Variant
	Dim vEndDT As Variant
	Dim dblResult As Long

	Set docCurrent = do it your way
	vStartDT = Fix (docCurrent.StartDate (0)) + Fraction (docCurrent.StartTime (0))
	vEndDT = Fix (docCurrent.EndDate (0)) + Fraction (docCurrent.EndTime (0))
	
	dblResult = Round ((vEndDT - vStartDT) *24 * 60, 0)
	
	Messagebox dblResult

[TMC]

Wichtig ist noch die Rundung, sonst kommt da leicht ein "unscharfer" Wert heraus:

@Bernhard: Date/Time - Behandlung mach ich eher selten, daher interessehalber die Nachfrage: Was kommt da "unscharf" raus?
Ich hätte jetzt eigentlich gemeint, mit den Funktionen Fix und Fraction und der Addition beider Values ist dann alles im grünen Bereich.

Matthias

[Semeaphoros]

Die Unschärfe ist in einem anderen Bereich zu suchen, mit Deinen Methoden trennst Du sauber Datums- und Zeitwerte und eliminierst allfällige von Notes hineingebastelte Standardwerte für die Felder, die nur das eine oder das andere berücksichtigen.

Bernhard rundet dann auch noch das Endresultat. Unschärfe kann dort durch das Rundungsproblem des Prozessors entstehen, da die Register nur endliche Grösse haben. Bernhards Schlussrundung schärft das schätzungsweise zu etwa 80%, um das noch ein wenig höher zu schrauben, müsste man mit einem Epsilon-Wert arbeiten und die Rundung noch ein wenig weiter "rechts" ansetzen. Ansonsten ist das genau das Thema, wo Bernhard sonst immer von mir Beweise verlangt .........  ..... Also Bernhard, beweise mal, warum die Rundung notwendig ist .... 

[koehlerbv]

Hallo Matthias,

ich arbeite in etlichen Projekten exzessiv mit Datum-/Zeit-Werten (Beispiel Zeiterfassung, bei der nun wirklich nichts schiefgehen darf) , ich weiss also, wovon ich rede. Jens hat es im ersten Teil seines Postings schon gut beschrieben: Der Prozessor kann nur endlich viele Stellen verarbeiten, und DT-Angaben werden als Datumsseriennummern gespeichert. Gerade der durch Fraction herausgefilterte Bruchteil (!) des Tages kann dazu führen, das weitere Rechenoperationen mit diesem Wert, die eigentlich ganze Zahlen ergeben sollten (hier: Minuten), doch wieder reelle Zahlen ergeben. Um dies nachzuvollziehen (gerade, wenn man keine reellen Datenreihen zur Verfügung hat), braucht man sich nur entsprechende Datenreihen generieren.

Bernhard

[TMC]

Hi Bernhard,

sorry, aber ich verstehe immer noch nicht ganz, warum hier eine Rundung erforderlich ist.

Die Designerhelp zu Fraction sagt ja auch:

Tip  It is always true that Fix(numExpr) + fraction(numExpr) = numExpr.

Was ja indirekt aufgrund Deiner Vorgehensweise heißen würde, man müsste Date/Time-Werte generell runden nach deren Bearbeitung, also unabhängig davon ob man das nun mit Fix/Fraction zusammensetzt oder nicht.

Wäre schön wenn Du als "Beweis" ein Beispiel nennen könntest. Wäre sicherlich auch für andere hilfreich, die sich mit Date/Time rumschlagen.

Danke,
Matthias

[koehlerbv]

Hallo Matthias,

es geht hier nicht um das Problem, Datum-/Zeitwerte generell runden zu müssen, sondern um den Umgang von Notes (bzw. prinzipiell: Den begrenzten Möglichkeiten, in einem binären System reelle Zahlen abzubilden) mit reellen Zahlen.

Heute (12.06.2005) früh um 8 Uhr liefert @Now oder in LS Now die Datumsseriennummer 38515,3333333333 zurück. Wir reden hier ja darüber, Operationen mit derartigen gebrochenen Zahlen (mit denen wiederum Operationen ausgeführt werden) wieder auf ganze Zahlen sicher zurückzuführen. Sicher heisst da für mich: Round mit den entsprechenden Parametern liefert mir wieder eine Ganzzahl, die ich dringend brauche. Diese Sicherstellung muss zudem an der frühestmöglichen (Rechen-)Operationsstelle erfolgen (logischerweise, da es ansonsten ggf. mit jedem Rechenschritt immer schlimmer wird).

Ich zitiere nochmals Semeaphoros, der genau das formuliert hat, was auch ich für sichere Programme an dieser Stelle für erforderlich halte:

Unschärfe kann dort durch das Rundungsproblem des Prozessors entstehen, da die Register nur endliche Grösse haben. Bernhards Schlussrundung schärft das schätzungsweise zu etwa 80%, um das noch ein wenig höher zu schrauben, müsste man mit einem Epsilon-Wert arbeiten und die Rundung noch ein wenig weiter "rechts" ansetzen.

Das nach "rechts verschieben" kann man sich aber angesichts der möglichen Unschärfen dank Round aber getrost schenken - wichtig ist das ergebnisnächste Runden ("ergebnisnah" heisst für mich hier: Genau an der Stelle, an der die Unschärfe auftreten kann).

Bernhard

[Marinero Atlántico]

Vorschlag (evtl. naiv) kannst du nicht eine Skriptlibrary erstellen.
In Pseudocode und die Variablennamen stimmen vermutlich auch nicht:

Name: SafeMath

Code

function division(divisor as Integer, dividend as Integer, round As Integer) As Double
division = dividend/divisor
division = round (division, round)
end function

etc...
Und die problematischen Rechenoperationen grundsätzlich über diese Funktionen laufen lassen. Klasse geht natürlich auch.

Gruß Axel
 

[koehlerbv]

Das ist ganz sicher gar keine schlechte Idee, Axel. Nur die Datentypen sind unpassend (Integer als Übergabewert und als Ergebnis Double). Ich sehe aber gerade, dass ich in meinem Code-Beispiel auch den Fehler gemacht habe, das erwünschte ganzzahlige Ergebnis einer Double-Variablen zuzuweisen - was natürlich kontraproduktiv ist.

Bernhard

[Semeaphoros]

Axel, wenn es eine allgemein gültige Lösung gäbe, wäre diese schon längstens in den Programmiersprachen oder unterdessen möglicherweise bereits auf Professorebene implementiert. Kurz zusammengefasst ist das Problem mit einer solche Lösung etwa so zu umschreiben:

Diese Korrektur geht davon aus, dass der Ist-Wert von einem korrekten Soll-Wert um ein Delta abweicht. Die Korrektur versucht nun, dieses Delta zu reduzieren (ein eliminieren ist leider nicht möglich). Dabei ist der korrekte Sollwert ja nicht wirklich bekannt, sondern wird vermutet. Leider kann dabei passieren, dass das Delta statt verkleinert auch vergrössert wird. Werden nun solche mit einem Fehler behafteten Operationen aneinandergehängt, dann zeigt sich das Phänomen der Fehlerfortpflanzung. Mit jeder neuen, korrigierten Operation wird die Fehlerwahrscheinlichkeit auch grösser. Von da kommt die ziemlich strikte Regel, dass solche Korrekturen erst am Endresultat vorzunehmen sind.

Soviel zum allgemeinen, im Speziellen für Zeit und Datum spricht das ganze dafür die NotesDateTime Klasse zu verwenden, anstatt die Berechnungen direkt am Zeitwert durchzuführen, in der Hoffnung, dass die interne Implementation dieser Klasse die Problematik so weit wie möglich berücksichtigt.

[Marinero Atlántico]

Jens.
Ich spreche nicht von einer allgemeingültigen Lösung. Bin mir aber ziemlich sicher, dass du in dem Falle von Bernhard eine Menge special-rundungs-math-code in eine spezielle Klasse auslagern kannst. Die mathematischen Operationen über diese Klasse werden natürlich mehr Prozessorenzyklen beanspruchen als einfach mit double zu arbeiten.
Wenn du aber in bestimmten Anwendungsfällen 0.0002 Milisekunden pro mathematische Operation verlierst, dafür aber dein code übersichtlicher wird und du weniger Fehler beim programmieren dieser Logik machst, kann es Sinn machen.

Z.B. gibt es ja in SQL auch den Datentyp Decimal, wo *diese* Floating point Rundungsfehler nicht auftauchen, da du eine fixe Anzahl an Dezimalstellen angeben kannst.

In Java gibt es z.B. die Klasse BigDecimal, die man für Fälle benutzen kann, wo floating point Rundungsfehler problematisch sind:
http://java.sun.com/j2se/1.5.0/docs/api/java/math/BigDecimal.html

Ich werd mal so weit ich es verstehe eine simple Klasse für Bernhards Fall erstellen und ihr entscheidet, ob das jetzt Sinn macht oder nicht.

AFAIK existiert z.B. in einigen Bereichen der Finanzmathematik die fixe Konvention, dass alle reele Zahlen auf 5 Stellen hinter dem Komma gerundet werden, bevor Operationen mit ihnen ausgeführt werden. 100% genau ist das natürlich auch nicht. Aber Bernhard benötigt ja auch nicht eine perfekte Genauigkeit, sondern einfach nur eine andere Unschärfe als die im Kontext von floating point.


später Axel

[Marinero Atlántico]

Man kann wesentlich genauere und größere Zahlen als double speichern. Nur eben nicht im Registerspeicher, sondern im Heap Speicher.
Theoretisch müßte es möglich sein einen Großteil des Heap-Speichers zur Definition einer einzigen Zahl zu verwenden. Nur sind dann die Operationen mit dieser Zahl nicht so besonders schnell.
Natürlich ist die Genauigkeit der Zahl dann auch durch die eingesetzte Hardware eingeschränkt. Man kann aber das Genauigkeitsconstraint nach außen verschieben.
Oder man benutzt eine *andere* Unschärfe wie z.B. in Decimal.

Axel

[animate]

ich sehe ehrlich gesagt keinen Grund, nicht die NotesDateTime-Klasse zu benutzen.
Kann mir das jemand mal erläutern, bitte?

Tipp:

erstelle zwei NotesDateTime-Objekte mit deinen beiden Daten und ermittle deren Differenz (TimeDifferenceDouble - Methode). Dann bekommst du das auf die Sekunde genaue Ergebnis in Sekunden und kannst es in ein Format deiner Wahl umrechnen (hh:mm, z.B.) und musst dich nicht mit runden, reellen Zahlen, Unschärfe, etc. beschäftigen.

[Semeaphoros]

Thomas, volle Zustimmung, das war der Inhalt meines letzten Satzes.

Axel, wenn ich die BigDecimal Defintion richtig gelesen habe, ist das ebenfalls ein Float-Datentyp, der hat im Prinzip genau die gleichen Probleme, vermutlich einfach durch höhere Genauigkeit für die Praxis etwas entschärft.

Was bei Oracle der Decimal-Datentyp genau ist, weiss ich nicht. Ich vermute mal, dass es sich um einen BCD-Datentyp handelt. Der zeigt das Phänomen natürlich deutlich weniger als irgend ein rein binärer Datentyp, hat dafür andere Einschränkungen und leidet vor allem an der Effizienz. Und -- in LotusScript bzw. Notes/Domino gibts den Typ nicht, kommt also geradezu nicht in Frage.