Głosuję za ustawieniem go w procedurze (lub domyślnie dla kolumny, dla insertów). Nie ma powodu, aby przekazywać wszystkie te informacje przez wszystkie warstwy, chyba że potrzebna jest dokładność mikrosekundowa, aby odróżnić np. kiedy użytkownik kliknął przycisk, a kiedy transakcja została zatwierdzona w bazie danych. Jest to szczególnie ważne, jeśli masz aplikację rozproszoną — czy chcesz polegać na synchronizacji wszystkich serwerów WWW/aplikacji, nie wspominając o stacjach roboczych użytkowników końcowych dla aplikacji klient/serwer? Możesz mieć serwery w różnych centrach danych, wszystkie z różnymi strefami czasowymi, niektóre obserwują czas letni, inne nie itp. DateTime.UtcNow powinien zniwelować większość tych różnic, ale i tak wracam do przekazywania wszystkich tych danych bez powodu. Baza danych wie, która jest godzina; niech przechowuje wartość dla Ciebie i trzymaj całą tę logikę poza aplikacją.
(Również, jeśli przechowujesz czas UTC, czy naprawdę potrzebujesz DATETIMEOFFSET? ? Jeśli tak, nadal potrzebujesz sposobu, aby procedura wiedziała, z której strefy czasowej pochodzą te informacje. Jeśli nie, prawdopodobnie powinieneś po prostu użyć SMALLDATETIME/DATETIME/DATETIME2 w zależności od wymaganej dokładności).
