Waarom slaat u UTC in de eerste plaats niet op in de DB? In de meeste gevallen DateTime moet worden opgeslagen in UTC, omdat het meestal verwijst naar een tijdstip. Dit geldt voor alles dat in fysieke zin naar tijd verwijst, en alles dat ervan uitgaat dat tijd monotoon, toenemend en uniek is, en geen van alle geldt voor de meeste lokale tijden.
Af en toe is het zinvol om lokale tijden te gebruiken:stel dat er elke dag om 9.00 uur een bus vertrekt. Dit betekent dat er 24 uur verstrijken tussen twee opeenvolgende gebeurtenissen. Als de tijdzone echter een zomertijd heeft, is dit eenmaal per jaar een interval van 23 uur, respectievelijk 25 uur.
Als u echter met dit soort gegevens moet ruziën, kunt u een eenvoudige DateTime doet het niet; Zomertijdregels kunnen veranderen, tijdzones kunnen veranderen, enz. In C# zijn de zomertijdregels die momenteel worden toegepast geldig, zelfs als de datum 'historisch' is. Datumberekening met historische data kan dus grote schade aanrichten. Als je hier echt mee om moet gaan, bewaar dan op zijn minst welke tijdzone waarin de tijd zich bevindt (niet alleen de offset, of zelfs alleen een isLocal vlag).
Het opslaan van tekstuele informatie in de database die binair kan worden opgeslagen lijkt me niet erg elegant, net zo min als het veranderen van de waarde in een tussenlaag. De eerste is inefficiënt en lijdt aan de eerder genoemde eigenaardigheden van de lokale tijd, de laatste heeft alleen het 2e probleem.
Trouwens, om het laatste te bereiken, zou je de eigenschap kunnen versieren met [BsonDateTimeOptions(Kind=DateTimeKind.Local)] , die de conversie voor u zal doen, maar lijdt natuurlijk aan dezelfde problemen.