Ich habe eine Methode, die eine Date-Eigenschaft von einer Quelle (entweder DataRow oder SqlDataReader ) bekommt:
Die Konvertierung scheint das Datum leicht zu ändern, so dass mein Test immer fehlschlägt.
Weiß jemand, warum diese Methode falsch konvertiert?
Am Ende der Methode sieht es so aus, als ob die Konvertierung in SqlDateTime etwas rundet:
Ja - der SQL Server DATETIME hat eine Genauigkeit von 3,33 ms - der .NET-Datentyp kann jedoch einzelne Millisekunden darstellen.
Daher werden Sie manchmal einige Rundungsprobleme haben.
Lesen Sie hier mehr über den DATETIME -Datentyp und seine Eigenschaften und Eigenarten:
Entmystifizieren des SQL Server DATETIME-Datentyps
Außerdem hat SQL Server 2008 eine Reihe neuer datumsbezogener Datentypen eingeführt - lesen Sie hier mehr darüber:
SQL Server 2008 Neue DATETIME-Datentypen
Diese Typen enthalten einen DATETIME2 -Datentyp, der auf 100ns genau ist.
Dies ist dokumentierte Genauigkeit von TSQL-Datum-Uhrzeit - siehe Abschnitt "Rundung der datetime fractional Second Precision" bei diesen Link von MSDN . Zitat aus dem Abschnitt:
datetime-Werte werden auf Inkremente von .000, .003 oder .007 gerundet Sekunden, wie in der folgenden Tabelle gezeigt.
.NET date-time hat eine bessere Genauigkeit.
Außerdem empfiehlt MS, neuere Datentypen (wie datetime2, date, time usw.) anstelle von date-time zu verwenden. Der Datentyp datetime2 , der mit Sql Server 2008 eingeführt wurde, hat eine ähnliche Genauigkeit (100 ns) (wie. NET Datum / Zeit-Struktur) und es unterstützt auch ISO 8601 String-Format, das Konvertierung von .NET Datum / Uhrzeit zu SQL Datum-Zeit einfacher machen würde ((wenn Sie gezwungen sind, Literale anstelle von parametrisierten Abfrage verwenden) und verlustfrei.
Das SqlDateTime-Objekt hat eine geringere Genauigkeit als das .NET DateTime-Objekt. Bei der Konvertierung in SQL verliert es daher an Genauigkeit.