Perché in primo luogo non memorizzi UTC nel DB? Nella maggior parte dei casi, DateTime dovrebbe essere memorizzato in UTC, perché di solito si riferisce a un punto nel tempo. Questo è vero per tutto ciò che si riferisce al tempo in senso fisico e tutto ciò che presume che il tempo sia monotono, crescente e unico, nessuno dei quali è vero per la maggior parte dei tempi locali.
Occasionalmente, l'uso dell'ora locale ha senso:supponiamo che un autobus parte ogni giorno alle 9:00. Ciò significa che tra due eventi consecutivi passano 24 ore. Tuttavia, se il fuso orario ha l'ora legale, sarà un intervallo di 23 ore, rispettivamente di 25 ore una volta all'anno.
Tuttavia, se hai bisogno di gestire questo tipo di dati, un semplice DateTime non fa il trucco; Le regole dell'ora legale possono cambiare, i fusi orari possono cambiare, ecc. In C#, le regole dell'ora legale che verranno applicate sono quelle che sono attualmente valido, anche se la data è 'storica'. L'aritmetica delle date con le date storiche può quindi causare il caos. Se hai davvero bisogno di far fronte a questo, dovresti almeno memorizzare quale fuso orario in cui si trova l'ora (non solo l'offset, o anche solo un isLocal bandiera).
La memorizzazione di informazioni testuali nel database che possono essere archiviate in binario non mi sembra molto elegante, né la modifica del valore in qualche livello intermedio. Il primo è inefficiente e soffre delle già citate particolarità dell'ora locale, quest'ultima ha solo il 2° problema.
A proposito, per realizzare quest'ultimo, potresti decorare la proprietà con [BsonDateTimeOptions(Kind=DateTimeKind.Local)] , che farà la conversione per te, ma soffre degli stessi problemi, ovviamente.
