TimeZoneInfo lo hace, si. (Es parte del marco .NET, no parte de C#; C# es solo el lenguaje que está usando). Sin embargo, no creo que eso sea lo que realmente quiera hacer.
¿Por qué está almacenando el DateTime en el servidor zona horaria de todos modos? Sería más sensato almacenarlo en UTC, en la mayoría de los casos. Aparte de cualquier otra cosa, si su servidor está en una zona horaria que observa el horario de verano, terminará con ambigüedad durante una hora por año, cuando el reloj retroceda. (La misma hora local ocurre dos veces).
Una vez que lo haya almacenado como UTC, también debe dárselo a su cliente Javascript como UTC. Si bien dice que tiene "algún script de Java que me compensará con los usuarios de UTC", eso dependerá del instante exacto en el tiempo. Por ejemplo, como estoy en el Reino Unido, mi compensación es a veces 0 ya veces +1 hora. Si le devuelve la UTC al cliente, eso puede calcular la hora local a partir de esa hora UTC. Su servidor no puede, a menos que pueda obtener una precisa representación de la zona horaria del cliente al servidor, lo que generalmente es algo complicado de hacer.
De nuevo, C# en sí mismo no es relevante aquí. No está claro a qué parte del marco .NET te refieres:TimeZone ? TimeZoneInfo ? DateTime ? TimeZoneInfo tiene datos históricos, pero solo si tiene una versión del sistema operativo compatible.
Bueno, en lo que a usted probablemente le importe. No tiene tantos datos históricos como TZDB, y tiene algunas representaciones muy extrañas para Rusia y Namibia, pero generalmente tiene la idea de que las reglas cambian.
