Por que você não está armazenando UTC no banco de dados em primeiro lugar? Na maioria dos casos, DateTime deve ser armazenado em UTC, porque geralmente se refere a um ponto no tempo. Isso é verdade para qualquer coisa que se refira ao tempo em um sentido físico, e qualquer coisa que assuma que o tempo é monótono, crescente e único, nenhum dos quais é verdade para a maioria dos tempos locais.

Ocasionalmente, usar os horários locais faz sentido:suponha que um ônibus saia todos os dias às 9h. Isso significa que 24 horas se passam entre dois eventos consecutivos. No entanto, se o fuso horário tiver um horário de verão, será um intervalo de 23h, respectivamente, de 25h uma vez por ano.

No entanto, se você precisar lidar com esse tipo de dados, um simples DateTime não faz o truque; As regras de horário de verão podem mudar, fusos horários podem mudar, etc. Em C#, as regras de horário de verão que serão aplicadas são as que estão atualmente válido, mesmo que a data seja 'histórica'. A aritmética de datas com datas históricas pode, assim, causar estragos. Se você realmente precisa lidar com isso, no mínimo, você deve armazenar qual fuso horário em que a hora está (não apenas o deslocamento, ou mesmo apenas um isLocal bandeira).

Armazenar informações textuais no banco de dados que podem ser armazenadas em binário não me parece muito elegante, nem alterar o valor em alguma camada intermediária. O primeiro é ineficiente e sofre das peculiaridades da hora local mencionadas anteriormente, esta última apresenta apenas o 2º problema.

BTW, para realizar o último, você pode decorar a propriedade com [BsonDateTimeOptions(Kind=DateTimeKind.Local)] , que fará a conversão para você, mas sofre dos mesmos problemas, é claro.