I wanted to point out that while I agree with the general approach (storing DateTime in UTC and converting into local time for display as well as accepting input in local time), it's not always what the requirements call for. If you're creating a meeting calendar, then of course it's perfect, or in fact anything where the time displayed need to be universal... but there are applications where the underlying intent is to different. For example, the office closes early, at 4:00 on new years eve this year. You don't want your folks who work in the USA leaving work at 16:00 Ukrainian time
I guess what I mean to get across is that DateTime work is tricky enough even when the intent is clear, but the intent is not always the same. So it's good to make sure you're solving the right problem.
I've been programming in C, C++, Visual Basic and C# for almost 30 years. I've worked at Sierra Systems, ViewStar, Mosaix, Lucent, Avaya, Avinon, Apptero and now Serena in various roles over my career.