Unfortunately, your possibilities "A" and "B" are presently the only two viable approaches.
The downside to option "A" is the maintenance cost, and that I have yet to see something that cleanly parses a valid time zone database (such as the IANA database) into SQL tables with functions that operate over those tables cleanly. This should be possible to do, I just haven't seen it yet. (Note that it does exist for MYSQL, and Oracle and Postgres have theirs built in, but nothing for MS SQL Server that I am aware of).
Option "B" is the usual recommendation, but you run into a few unachievable use cases like those you mentioned. A more commonly desired use case is to emit a "daily report" for a specific time zone. Grouping by date is unachievable when a UTC datetime has to first be converted to a specific time zone. Also, one might want to run these from SSRS or other reporting tools.
Option "C" sounds promising, but there is a problem: The TimeZoneInfo
class can't operate in SQLCLR unless you enable "unsafe" mode, which creates a security and stability risk that is undesirable for a production environment. You can read more here.
I am working on a better solution, which is to modify Noda Time to be usable from a "safe" mode SQLCLR environment. This is on the roadmap, and preliminary testing looks promising. It would require you to use IANA TZDB time zones, which is probably a good idea anyway. When done, you will have some simple user-defined functions to do timezone conversions, which rely on the code and data of the Noda Time assembly. I will update this post when it is ready, but I don't have an ETA as of yet.
UPDATE After a lot of testing, I decided it would be better to build a SQL-based solution, similar to what is described in option A. You can now use my SQL Server Time Zone Support project, which imports IANA time zone data (via Noda Time) directly into SQL-Server tables. It then binds that information to functions you can call for easy conversion. It is reliable, and maintainable, and works in all SQL Server environments, 2008 R2 and higher, including Azure SQL DB.