Was um alles in der Welt haben sie hier gedacht? Es erscheint mir hässlich schlecht, eine Methode zu erstellen, die ein Double braucht, wenn sie nicht mit Bruchzahlen arbeitet. Warum haben sie das nicht mit einem Aufruf von AddTicks umgesetzt und den Bruch richtig gehandhabt? Oder zumindest ein Int, so dass es für Anrufer transparent ist?
Ich vermute, es muss einen guten Grund geben, warum sie es so umgesetzt haben, aber ich kann mir nicht vorstellen, was es sein könnte. Kann mir jemand Einblick geben?
EDIT: nur um den Punkt weiter zu betonen:
%Vor%Es ist ein Kompromiss, nicht völlig unvernünftig. Das übergebene Argument muss gerundet werden, um die Auflösung von DateTime zu verarbeiten. Die Rundung auf die Genauigkeit eines Ticks (100 Nanosekunden) ist ein Problem. Double verfügt nicht über genügend signifikante Ziffern, um den gesamten Bereich der möglichen Daten zu überbrücken. 10000 Jahre x 365 x 24 x 3600 x 1000 x 10000 = 3E18, Doppel hat nur 15 signifikante Ziffern. Es gibt kein Problem durch das Runden auf eine Millisekunde, 3E14 ist nur gut genug (was sind die Chancen?)
Die Problemumgehung ist einfach, verwenden Sie einfach AddTicks (1.5 * 10000).
Es scheint ziemlich bizarr. Mein einziger Gedanke ist, dass sie es vielleicht besser fanden, auf die nächste Millisekunde zu runden, anstatt zu riskieren, dass der Anrufer ein Double zu einem Int abschneidet. Ja, das ist eine ziemlich schwache Erklärung. Entschuldigung.
MSDN :
Der Wert in Millisekunden wird auf die nächste ganze Zahl gerundet, bevor er zur angegebenen DateTime hinzugefügt wird.
Wie DateTime kann nichts weniger als Millisekunden lösen, auch gebrochene Millisekunden Hinzufügen die falsche Sache zu tun wäre.
Ich würde sagen, dass sie einen Kompromiss gemacht haben - es ist besser, dann eine Ausnahme zu werfen und würde funktionieren, wie die meisten Programmierer erwarten würden.