Je vote pour le mettre dans la procédure (ou la valeur par défaut pour la colonne, pour les inserts). Il n'y a aucune raison de transmettre toutes ces informations à travers toutes les couches, sauf si vous avez besoin d'une précision à la microseconde pour différencier, par ex. lorsque l'utilisateur a cliqué sur le bouton par rapport au moment où la transaction a été validée dans la base de données. Cela est particulièrement vrai si vous avez une application distribuée - voulez-vous compter sur la synchronisation de tous vos serveurs Web/d'applications, sans parler des postes de travail des utilisateurs finaux pour les applications client/serveur ? Vous pouvez avoir des serveurs dans différents centres de données, tous avec des fuseaux horaires différents, certains observant l'heure d'été, d'autres non, etc. DateTime.UtcNow devrait effacer la plupart de ces différences, mais je recommencerais à transmettre toutes ces données sans raison. La base de données sait quelle heure il est; laissez-le stocker la valeur pour vous et gardez toute cette logique hors de l'application.
(Aussi, si vous stockez l'heure UTC, avez-vous vraiment besoin de DATETIMEOFFSET ? Si c'est le cas, vous avez encore besoin d'un moyen pour que la procédure sache de quel fuseau horaire ces informations proviennent. Si ce n'est pas le cas, vous devriez probablement simplement utiliser SMALLDATETIME/DATETIME/DATETIME2 en fonction de la précision requise.)
