Ik stem voor het instellen ervan in de procedure (of de standaard voor de kolom, voor tussenvoegsels). Er is geen reden om al deze informatie door alle lagen te laten gaan, tenzij je een nauwkeurigheid van microseconden nodig hebt om b.v. wanneer de gebruiker op de knop klikte versus wanneer de transactie in de database werd vastgelegd. Dit is met name het geval als u een gedistribueerde toepassing heeft - wilt u erop vertrouwen dat al uw web-/toepassingsservers synchroon lopen, laat staan de werkstations van eindgebruikers voor client-/server-apps? Mogelijk hebt u servers in verschillende datacenters, allemaal met verschillende tijdzones, sommige met zomertijd, andere niet, enz. DateTime.UtcNow zou de meeste van die verschillen moeten uitwissen, maar ik zou nog steeds teruggaan naar het doorgeven van al die gegevens zonder reden. De database weet hoe laat het is; laat het de waarde voor u opslaan en houd al die logica uit de toepassing.
(Ook als je UTC-tijd opslaat, heb je dan echt DATETIMEOFFSET nodig ? Als dat het geval is, moet u voor de procedure nog een manier hebben om te weten uit welke tijdzone deze informatie afkomstig is. Zo niet, dan moet u waarschijnlijk gewoon SMALLDATETIME/DATETIME/DATETIME2 gebruiken afhankelijk van de vereiste nauwkeurigheid.)