Где установить значение даты и времени в формате UTC в n-уровневом приложении: уровень представления, домен или база данных?

Похоже, это должен быть очевидный вопрос, но у меня были некоторые проблемы с поиском хорошего ответа. Я создаю n-уровневое приложение, которое должно быть чувствительным ко времени UTC. Значения могут быть обновлены, и когда они являются временными метками, записываются. Это включает транзакции в базе данных, где обновления или вставки влияют на столбцы даты и времени.

Чтобы дать некоторый контекст, я использую SQL 2008 R2 + с DATETIMEOFFSET (2) для большинства моих столбцов datetime. Я рассматриваю возможность размещения обновлений временных меток в хранимых процедурах, чтобы их не нужно было передавать по сети. Это сэкономит полосу пропускания по мере роста системы, что является хорошей вещью ... и может быть использовано для проверки, если данные изменяются (первые выигрыши) на общих данных. Недостатком является то, что первым, кто отправит транзакцию, может быть не тот, кто выиграет, если у них возникнет более медленное время отклика в их экземпляре приложения.

Каков идеальный или рекомендуемый способ обработки данных времени UTC в этом контексте?

Установите его в SPROC с помощью SYSUTCDATETIME () ИЛИ ...Установите его в приложении с помощью DateTimeOffset.Now или DateTime.UtcNow.

Если два выше, было бы рекомендовано запустить это на уровне представления и передать его через службу на уровень домена или просто установить его, когда он попадает в домен на серверной части службы?

Как вы можете видеть, здесь есть много вариантов, и я склоняюсь к базе данных ... но я был бы признателен за любые советы или слова предупреждения, прежде чем я продолжу строить эту вещь.

Примечание: я также отслеживаю геопространственную информацию ... но это не сложная система реального времени. Реальное время пользователя более чем адекватно.

ОБНОВЛЕНИЕ: я буду использовать DateTimeOffset в приложении. Мои исследования привели меня к тому, что яМожно надежно сравнить любые типы DateTime, сначала вызвав ToUniversalTime для каждого из них. Эта стратегия терпит неудачу, если (и только если) точно один из них имеет тип DatTimeKind, равный "Неопределенные". Его вероятность неудачи является еще одной причиной для предпочтения DateTimeOffset " - C # 4.0 в двух словах, O 'Рисовые книги.

Ответы на вопрос(1)

Ваш ответ на вопрос