Dlaczego w ogóle nie przechowujesz czasu UTC w DB? W większości przypadków DateTime powinien być przechowywany w UTC, ponieważ zwykle odnosi się do punktu w czasie. Odnosi się to do wszystkiego, co odnosi się do czasu w sensie fizycznym, i wszystkiego, co zakłada, że czas jest monotoniczny, rosnący i niepowtarzalny, z których żadne nie jest prawdziwe dla większości czasów lokalnych.
Czasami użycie czasu lokalnego ma sens:załóżmy, że autobus odjeżdża codziennie o 9 rano. Oznacza to, że pomiędzy dwoma kolejnymi wydarzeniami mijają 24 godziny. Jeśli jednak strefa czasowa ma czas letni, będzie to interwał 23- i 25-godzinny raz w roku.
Jeśli jednak potrzebujesz zebrać tego rodzaju dane, prosty DateTime nie załatwia sprawy; Reguły czasu letniego mogą się zmieniać, strefy czasowe mogą się zmieniać itd. W języku C# stosowane będą reguły czasu letniego, które są obecnie ważne, nawet jeśli data jest „historyczna”. Arytmetyka dat z datami historycznymi może więc siać spustoszenie. Jeśli naprawdę musisz sobie z tym poradzić, przynajmniej powinieneś przechowywać które strefa czasowa, w której znajduje się czas (nie tylko przesunięcie, czy nawet tylko isLocal flaga).
Przechowywanie informacji tekstowych w bazie danych, które można przechowywać w postaci binarnej, nie wydaje mi się zbyt eleganckie, podobnie jak zmiana wartości w jakiejś środkowej warstwie. Pierwsza jest nieefektywna i cierpi na wspomniane wcześniej osobliwości czasu lokalnego, ten ostatni ma tylko drugi problem.
BTW, aby osiągnąć to drugie, możesz udekorować właściwość za pomocą [BsonDateTimeOptions(Kind=DateTimeKind.Local)] , który dokona konwersji za Ciebie, ale ma oczywiście te same problemy.
