No can do, and frankly is a _very_ reductive stock response.
Anyone working with Date Times more than even months into the future will have pain. Politics will mess you up. You've made a reservation for 16:00 at that fancy pants restaurant with a 6 month waiting list. But now the government have decided that Daylight Savings are too much hassle, and suddenly your 16:00 reservation is off by an hour (or whatever the DS shift is for your region.)
Then there is industry specific scenarios - logistics for example. They know the plane is landing at 18:00, but we haven't confirmed the TZ yet. Not because the airport doesn't know what timezone it is, but because the carrier hasn't confirmed which airport they are landing at. They just know it's at 18:00. DateTime is utterly terrible with "unknown"
https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...
You mean local time zone? Just use UTC everywhere, nothing else will ever work no matter how you design it. DateTimeOffset miiight work too, but you'll extract UTC from it to do anything meaningful anyway, so it may as well be UTC all the way down.