Runtime: TimeZones y DateTimeOffset

_Este problema se ha movido de un ticket en la comunidad de desarrolladores ._

Actualmente, DateTimeOffset no tiene opciones para las conversiones de zona horaria y la API de Windows para TimeZoneInfo no tiene soporte para DateTimeOffset

esto lleva a tener que escribir código para convertir un desplazamiento de fecha y hora en una fecha y luego usar TimeZoneInfo para convertir a una nueva fecha y hora y luego volver a un DateTimeOffset para que se conserven el punto en el tiempo y la zona horaria previstos.

este conjunto de conversiones entre formatos y las llamadas api relacionadas crea la posibilidad de errores en la conversión que pueden no ser fáciles de detectar si el desarrollador no está completamente versado en los detalles de las zonas horarias.

Creo que se creará un nuevo conjunto de métodos o una nueva biblioteca de clases que unifique TimeZoneInfo y DateTimeOffset para permitir que un desarrollador solicite que un datetimeoffset se convierta en una nueva zona horaria y no necesite entrar en una cadena de conversiones. esto reduciría los errores y simplificaría el uso de DateTimeOffset para la mayoría de los desarrolladores

Comentarios originales

Denny Figuerres el 15/03/2019, 08:16 AM:

También DateTimeOffset ToLocal asume la fecha y hora del servidor / zona horaria, lo que no ofrece ninguna opción para convertir a una zona horaria de usuario para una aplicación en la web, el cliente puede estar en una zona horaria diferente a la del cliente del navegador.

y es posible que un navegador necesite ver una fecha para una zona horaria en la que no se encuentra.

Jane Wu [MSFT] el 18/3/2019, 01:36 a. M.:

Gracias por tomarse el tiempo para brindar su sugerencia. Haremos algunas comprobaciones preliminares para asegurarnos de que podamos seguir adelante. Proporcionaremos una actualización una vez que el equipo de producto haya solucionado el problema.