Office: (Office 2016) Uhzreit in Zahl umwandeln

Wenn man schon rechnet statt unmittelbar verwendet (Indexnutzung für Abfragen), wäre die Verwendung eines UNIX-Timestamps eine Alternative. Dort wird der DateTime-Wert in Sekunden seit dem 01.01.1970 ausgedrückt, ist also eine Ganzzahl (Long) und damit frei von Rundungsdifferenzen.
Die Hin- und Herrechnung UNIX-Timestamp - DateTime per DateAdd / DateDiff ist auch überschaubar.

 

Vielen Dank für das Beispiel! Das grundsätzliche Problem der Fließkommatypen war mir bewusst, aber dass es bei einer Berechnung, explizit unter Verwendung der dafür vorgesehenen Datumsfunktionen, auch zu diesen Problemen kommt, hat mich doch etwas überrascht. - Bei genauerer Betrachtung ist natürlich klar, dass eine Minute auch von DateAdd nur mit potenziellen Rundungsungenauigkeiten dargestellt werden kann. Erschreckend allerdings, dass diese noch nicht mal in der Double-Repräsentation der Datumswerte sichtbar werden.

@Nouba und @ebs17: Ihr habt natürlich beide recht. Dennoch muss ich hier Marsu65 und auch markusxy zustimmen, dass es nicht intuitiv ist, wenn zwei definierte Datumswerte nicht direkt verglichen werden können. - Dass einer der beiden Werte über mehrere Rechenschritte errechnet wurde, sollte dabei keinen Unterschied machen.

 

Ich hatte immer das Problem, dass wenn ich berechnete Werte über SQL Filter anzeigen wollte aufgrund der minimalen Unterschiede öfter mal nichts gefunden wurde.

So kann man entweder jeden berechneten Wert runden oder man überführt für die Berechnung in Ganzzahlen.

 

Ich habs bis jetzt etwas komplizierter gemacht.
Das werde ich künftig verwenden.

 

Hallo!

In VBA könnte man für den Vergleich auch DateDiff verwenden, wenn "auf Sekunde genau" ausreicht.

mfg
Josef

 

Hallo zusammen!

Hat imho weniger mit Normalisierung von Gleitkommazahlen, sondern mehr mit
dem Problem periodischer Binärzahlen zu tun.

Eine Zeitangabe erst in einen String und zurück in ein Date zu konvertieren
(Date-/TimeValue) ist zwar programmatisch eine Lösung, sollte dann aber imho
direkt in der DateAdd-Funktion integriert sein. Jedenfalls sollte bei der Beschreibung
der Funktion ein entsprechender Hinweis auf deren Ungenauigkeiten zu finden sein.

@markus
selbes Prinzip, etwas kürzer als der Vorschlag von Nouba
Code:

was schneller ist, habe ich nicht getestet.
Ich selbst bilde Kalenderdaten mit Uhrzeit nur noch über die Date-/Timeserial-Funktionen.
Dabei sind mir bis jetzt keine Ungereimtheiten aufgefallen.

@sonic

Die Differenzen treten erst so ab der 11. Nachkommastelle auf.
Bei Sekundenintervallen teilweise sogar erst ab der 20.!

 

\@Marsu65
CDate ist grundsätzlich extrem langsam.

Ich habs immer so gemacht:

Datumsvariable = FormatDateTime(daDatum, vbGeneralDate)

Ich gehe mal davon aus, dass jede Umwandlung in Text verhältnismäßig langsam ist.

Manchmal reicht es nur eine Sekunde abzuziehen und schon passt es nicht. Es geht da immer nur um den Ausgangswert.Wenn man nach der Berechnung rundet passt alles.

 

Hallo zusammen,

da es mich interessiert hat, ein einfacher Speed-Test:
Code:

Date-/TimeSerial ist trotz der Zerlegung mehr als doppelt so schnell wie alle anderen.
Nicht, dass es bei den Werten in einer Anwendung eine Rolle spielen dürfte ... *wink.gif*

Woher hast du diese Erkenntnis?

 

\@Marsu65, danke für den Vergleich.
Bei mir habe ich nur den Vergleich des Convertierens von String zu Datum gemacht. Serial Funktion vs. CDate und das ohne den Wert bei jedem Durchlauf zu ändern.

 

CDate macht mit einem Datumswert gar nichts, weil es nichts zu wandeln gibt.

Hier mal mein Benchmarking: Code:

Mit diesen Resultaten auf meinem angestaubten Notebook. Code:

Wie man schön sieht, verbrät DateASdd ca. 1/3 der Zeit, vermutlich deswegen, weil beim Wechsel in die Vorzeit der Epoche Besonderheiten zu beachten sind. Denn eine Sekunde nach 0 (30.12.1899 00:00:00) entspricht einem Wert von -1,99998842592593!

 

\@Nouba
na gut, akzeptiert. *winner

 

\@Nouba,
ich versuche grade einen String von einem Datum per API. -> https://docs.microsoft.com/de-de/pre...arbstrfromdate
Was mache ich falsch?

Code:

Edit: Wie ich jetzt bemerkt habe erhalte ich einen Pointer zu einem BSTR als Rückgabewert.
Muss ich den BSTR dann auch irgendwie freigeben, oder passiert das automatisch?

Edit: Wenn ich den Befehl mehrfach aufrufe, wird die Adresse sofort wieder verwendet wenn ich per SysFreeString freigebe. Also werde ich es mit der Freigabe verwenden.

 

Du erhältst als Resultat einen Pointer auf einen BStr, den Du dann in den Puffer kopieren kannst. Code:

PS: da wird die API selbst einen Puffer bereitstellen.

 

\@Nouba,
danke, zwischenzeitlich hatte ich es schon geschafft.

Was mir nie klar ist.
Wie komme ich zu den Konstanten?
Manchmal sind sie Online zu finden, oder sie sind im win32api.txt File enthalten.

Gibt es da noch eine andere Quelle?
LG M

 

Win-API vs. VBA-Methode, das ist unfair. *rolleyes.gif*
Trotzdem *10points