Runtime: 时区和日期时间偏移

创建于 2019-11-27  ·  1评论  ·  资料来源: dotnet/runtime

_此问题已从开发者社区的工单中移出。_


目前 DateTimeOffset 缺少时区转换选项,TimeZoneInfo 的 windows api 不支持 DateTimeOffset

这导致必须编写代码将日期时间偏移量转换为日期时间,然后使用 TimeZoneInfo 转换为新的日期时间,然后返回到日期时间偏移量,以便保留预期的时间点和时区。

格式和相关 api 调用之间的这组转换可能会导致转换错误,如果开发人员不完全了解时区的详细信息,则可能不容易发现这些错误。

我认为创建一组新的方法或一个新的类库来统一 TimeZoneInfo 和 DateTimeOffset,以允许开发人员要求将 datetimeoffset 转换为新的时区,而不需要进入转换链。 这将减少错误并使大多数开发人员更容易使用 DateTimeOffset


原始评论

Denny Figuerres 于 2019 年 3 月 15 日上午 08:16:

同样 DateTimeOffset ToLocal 假设服务器日期时间/时区没有提供任何选项来转换为网络上的应用程序的用户时区,客户端可能与浏览器客户端位于不同的时区。

并且浏览器可能需要查看它们不在的时区的日期。

Jane Wu [MSFT] 于 2019 年 3 月 18 日上午 01:36:

感谢您抽出宝贵时间提供您的建议。 我们将进行一些初步检查,以确保我们可以进一步进行。 一旦产品团队对问题进行分类,我们将提供更新。

api-needs-work api-suggestion area-System.Runtime

最有用的评论

同样 DateTimeOffset ToLocal 假设服务器日期时间/时区没有提供任何选项来转换为网络上的应用程序的用户时区,客户端可能与浏览器客户端位于不同的时区。

并且浏览器可能需要查看它们不在的时区的日期。

这个。 这就是DateTimeKind损坏的原因。 Utc / Local / Unknown (或类似 API 中的Other )显示对域的误解。

我将重申,我们应该提供一个第一方完整的、现代的、日期/时间 API,它看起来类似于 java.time 和 NodaTime。
请注意,在大多数情况下, DateTimeOffset也不是正确的域类型,因为非绝对即时信息通常最好记录为DateTimeZoned (在添加时自动更新偏移量)。

>所有评论

同样 DateTimeOffset ToLocal 假设服务器日期时间/时区没有提供任何选项来转换为网络上的应用程序的用户时区,客户端可能与浏览器客户端位于不同的时区。

并且浏览器可能需要查看它们不在的时区的日期。

这个。 这就是DateTimeKind损坏的原因。 Utc / Local / Unknown (或类似 API 中的Other )显示对域的误解。

我将重申,我们应该提供一个第一方完整的、现代的、日期/时间 API,它看起来类似于 java.time 和 NodaTime。
请注意,在大多数情况下, DateTimeOffset也不是正确的域类型,因为非绝对即时信息通常最好记录为DateTimeZoned (在添加时自动更新偏移量)。

此页面是否有帮助?
0 / 5 - 0 等级