4

I think you're on the right track with using the built in TimeZoneInfo class. The ID should never change, but the name will (I learned that lesson the hard way when several changed between xp and vista). I have used a virtually identical approach (UTC only at the service and db layers, local time on the web server & client) and it worked just fine. ...


3

Have you tried SQLite? It's a self contained embedded lightweight SQL database. A lot of applications use it to store user settings and other persistence use cases in Desktop Apps - all the major Browsers, OSes, Skype and more. Of course this would mean your user settings won't be "Human Readable" as such. Not as much as XML anyway. Is that a requirement ...


2

It is very difficult to securely delete something from the registry: the registry hives are synchronized with persistent files these hives may be subject to logging, so that overwriting a value is not necessary sufficient if the hive files are on an SSD, then it will anyway be very difficult to remove every trace from the old value in addition the hive ...


1

Your approach is fine so far. The "Unit-of-Work" class should get the responsibility to keep track of the changes to your "settings entity" for one "transaction" (it could do this, for example, by keeping a list of commands or changed objects, if there would be more than one object involved), and the abstract repository should provide an abstraction for the ...


1

One other thing to consider: there is a difference between xST and xDT; for example, Arizona is MST, i.e. they do not adhere to DST, so effectively they're in Mountain during the winter and Pacific during the summer.


Only top voted, non community-wiki answers of a minimum length are eligible