.net - UTC 和夏令时方案

Question

我正在使用 UTC 在数据库中存储数据和时间值。这些值在客户端或每个客户端时区转换为本地时间。我从 MSDN article 中踩到了这些场景，其中从 UTC 显示时间似乎在夏令时造成问题。

Someone living on the east coast of the United States types in a value like "Oct 26, 2003 01:10:00 AM".

1) On this particular morning due to daylight savings, at 2:00 AM, the local clock is reset to 1:00 AM, creating a 25-hour day. Since all values of clock time between 1:00 AM and 2:00 AM occur twice on that particular morning—at least in most of the United states and Canada, the computer really has no way to know which 1:10 AM was meant—the one that occurs prior to the switch, or the one that occurs 10 minutes after the daylight savings time switch.

2) Similarly, the problem happens in the springtime when, on a particular morning, there is no such time as 2:10 AM. The reason is that at 2:00 on that particular morning, the time on local clocks suddenly changes to 3:00 AM. The entire 2:00 hour never happens on this 23-hour day.

您是如何处理第 1 种情况的，当时您可能有 4 笔交易，两笔在切换前，两笔在夏令时切换后？如何向用户显示交易的时间，因为由于轮类，最后两个交易可能比前两个交易更早显示。？有时，它可能被证明是不合逻辑的，例如:在邮件链中。

添加:

要添加有关上下文的更多信息，在客户端(或通过 Web 服务与服务器通信的任何客户端应用程序)上运行的 RIA 应用程序(例如 Silverlight/Flash)允许用户选择交付时间或使用 PC 本地时间安排时间。

如果我可以检查给定输入时间的无效时间，我可能会提醒用户。此外，对于旅行者来说，时区需要在时间点找到，而不是基于用户选择，因为他们可能会在区域之间移动，将时区保存在用户配置文件中也无济于事。

一些用于评估输入时间的 C# 测试示例:

//2:30 am CT to UTC --> 8:30 am  
DateTime dt = new DateTime(2009, 03, 08, 2, 30, 00, DateTimeKind.Local);  

//8:30 am UTC to CT --> 3:30 am.. which is as expected  
DateTime dt1 = new DateTime(2009, 03, 08, 8, 30, 00, DateTimeKind.Utc);  

//check for daylight saving time returns false.. ??  
TimeZoneInfo.Local.IsDaylightSavingTime(dt);  

//check for daylight saving time returns true  
TimeZoneInfo.Local.IsInvalidTime(dt);  

Answer 1

这些场景是提倡使用夏令时的案例。只要您以 UTC 格式存储和排序值，显示什么并不重要。也就是说，如果您正确使用 UTC，那么这些场景中出现的问题就会得到解决。

是的，看到这样的记录会令人困惑:12:30, 1:20, 1:10, 3:30 但如果它们是根据 UTC 排序的(实际发生的情况)，我认为这是正确的方式做吧。

SO 通过以 UTC 记录所有内容，然后以 UTC 或相对时间(如“17 分钟前...”)显示所有内容，完全避免了这个问题。

如果您指的是评论中建议的用户提供的日期/时间，我有一些坏消息要告诉您:它很糟糕。我认为最好、最明显的解决方案是选择一个规则并执行它。如果你真的需要完美地处理它，你的 UI 将需要扩展以迂回地处理这种每年仅发生 1 小时的边缘情况，然后只处理非实时创建的交易(因为如果它们是真实的- 时间，您会知道 DST 等效项)。