_此问题已从开发者社区的工单中移出。_
目前 DateTimeOffset 缺少时区转换选项,TimeZoneInfo 的 windows api 不支持 DateTimeOffset
这导致必须编写代码将日期时间偏移量转换为日期时间,然后使用 TimeZoneInfo 转换为新的日期时间,然后返回到日期时间偏移量,以便保留预期的时间点和时区。
格式和相关 api 调用之间的这组转换可能会导致转换错误,如果开发人员不完全了解时区的详细信息,则可能不容易发现这些错误。
我认为创建一组新的方法或一个新的类库来统一 TimeZoneInfo 和 DateTimeOffset,以允许开发人员要求将 datetimeoffset 转换为新的时区,而不需要进入转换链。 这将减少错误并使大多数开发人员更容易使用 DateTimeOffset
同样 DateTimeOffset ToLocal 假设服务器日期时间/时区没有提供任何选项来转换为网络上的应用程序的用户时区,客户端可能与浏览器客户端位于不同的时区。
并且浏览器可能需要查看它们不在的时区的日期。
感谢您抽出宝贵时间提供您的建议。 我们将进行一些初步检查,以确保我们可以进一步进行。 一旦产品团队对问题进行分类,我们将提供更新。
同样 DateTimeOffset ToLocal 假设服务器日期时间/时区没有提供任何选项来转换为网络上的应用程序的用户时区,客户端可能与浏览器客户端位于不同的时区。
并且浏览器可能需要查看它们不在的时区的日期。
这个。 这就是DateTimeKind
损坏的原因。 Utc
/ Local
/ Unknown
(或类似 API 中的Other
)显示对域的误解。
我将重申,我们应该提供一个第一方完整的、现代的、日期/时间 API,它看起来类似于 java.time 和 NodaTime。
请注意,在大多数情况下, DateTimeOffset
也不是正确的域类型,因为非绝对即时信息通常最好记录为DateTimeZoned
(在添加时自动更新偏移量)。
最有用的评论
这个。 这就是
DateTimeKind
损坏的原因。Utc
/Local
/Unknown
(或类似 API 中的Other
)显示对域的误解。我将重申,我们应该提供一个第一方完整的、现代的、日期/时间 API,它看起来类似于 java.time 和 NodaTime。
请注意,在大多数情况下,
DateTimeOffset
也不是正确的域类型,因为非绝对即时信息通常最好记录为DateTimeZoned
(在添加时自动更新偏移量)。