Ich stimme dafür, es in der Prozedur festzulegen (oder die Standardeinstellung für die Spalte, für Einfügungen). Es gibt keinen Grund, all diese Informationen durch alle Schichten zu leiten, es sei denn, Sie benötigen eine Genauigkeit im Mikrosekundenbereich, um z. wann der Benutzer auf die Schaltfläche geklickt hat vs. wann die Transaktion in der Datenbank festgeschrieben wurde. Dies gilt insbesondere, wenn Sie eine verteilte Anwendung haben – möchten Sie sich darauf verlassen, dass alle Ihre Web-/Anwendungsserver synchron sind, geschweige denn Endbenutzer-Workstations für Client/Server-Apps? Möglicherweise haben Sie Server in unterschiedlichen Rechenzentren, alle mit unterschiedlichen Zeitzonen, manche mit Sommerzeit, manche nicht usw. DateTime.UtcNow sollte die meisten dieser Unterschiede auslöschen, aber ich würde trotzdem all diese Daten ohne Grund weitergeben. Die Datenbank weiß, wie spät es ist; Lassen Sie es den Wert für Sie speichern und halten Sie die gesamte Logik aus der Anwendung heraus.
(Auch wenn Sie die UTC-Zeit speichern, brauchen Sie wirklich DATETIMEOFFSET ? Wenn dies der Fall ist, benötigen Sie noch eine Möglichkeit, damit das Verfahren weiß, aus welcher Zeitzone diese Informationen stammen. Wenn nicht, sollten Sie wahrscheinlich einfach SMALLDATETIME/DATETIME/DATETIME2 verwenden abhängig von der erforderlichen Genauigkeit.)
