sql-server - 在SQL Server中获取特定时区的本地日期/时间

Question

使用SQL Server 2008+。 SQLCLR不是一个选择。

我的情况是所有数据都存储在UTC中。我需要通过确定某个当地时间（例如上午8点）在UTC中进行比较来对该数据进行比较。当地时间的时区将逐行变化。 （存储了每一行的时区，所以这不是问题。）某些本地时间没有与之关联的日期。总是“早上8点”。

我在数据库中有时区数据，并且如果时区遵循夏时制，这也会告诉我基本UTC偏移量。

但是现在我有点卡住了。

我的问题是，为了进行夏令时调整，我需要知道特定时区中的当前日期/时间是否在特定范围内，但是我只能转换为适当的本地时间以进行检查，如果我知道如果是夏令时！换句话说，除非我知道UTC偏移量是否由于夏时制而关闭，否则如何检查夏令时？

这是鸡和鸡蛋的问题。

在我看来，唯一的解决方案是能够拥有一个表，该表可以按时区计算夏令时偏移量。

有想法吗？

Answer 1

您在这里确实有一个模棱两可的问题，但这不是鸡和蛋的问题。

您缺少的信息是“什么定义了一天？”我知道，这听起来很疯狂，但是“一日”并不是一个普遍的概念。这是本地的。

只需一分钟，将时区，夏令时和UTC放在一旁。如果我问你，“我们现在凌晨8点有几小时？”您可以给我两个不同的答案。现在是晚上7点，因此您可能会说“ 11个小时”-因为那是今天我们从早上8点开始的时间。但是我也可以说“ 13个小时”，因为那是明天上午8点到现在的时间。现在，在这个非常简单的示例中，您可以采用两种不同的方式之一来消除歧义。您可能会说“最后8AM”或“接下来8AM”。或者您可能会说“今天发生的一切”。

现在回到UTC的概念。什么是“ UTC日”？好吧，我们知道这是24小时，因为UTC不会遵循任何夏令时。但是说它运行在“ UTC午夜到午夜”，并不是一个非常有意义的措施。当然，有些地方使用了此定义（例如，StackOverflow的统计信息引擎）。但是对于大多数人来说，我们认为在自己的当地时间是“今天”。

因此，我不能说“今天上午8点发生的任何事情”。您唯一的日期度量是UTC日期。您将不知道应该查看哪个本地日期。让我们举一个真实的例子：


我住在亚利桑那州的凤凰城，所以我的时区偏移是UTC-7。我们这里没有DST。
目前是当地时间2013年6月14日晚上7点。
就是2013年6月15日，世界标准时间凌晨2点。


现在，我将该时间记录在数据库中，然后我问：


“我们到亚利桑那州时间上午8点有多远？”
根据我掌握的信息，我不知道该在6月14日上午8点还是在6月15日上午8点。只有后者属于同一UTC日期，但是我当然会对其中任何一个感兴趣。


如果您可以在业务逻辑中决定上一次或下一次需要，则可以解决此问题。只需将UTC日期时间转换为本地时区。然后向前或向后滚动到所需时间。如果您所在的时区具有夏令时，并且您一路经过过渡日期，则可以对此进行调整。

您也可以选择两者中最接近的时间，但是当然，这完全取决于您的业务逻辑。

另一种方法是使用您正在比较的UTC时间来确定您今天所处的本地时间。因此，在上面的示例中，亚利桑那州当地的6月14日是从6月13日17:00 UTC到6月14日17:00 UTC。

因此，总而言之，您想知道“ DST中的上午8点是这个UTC日期时间吗？”，如果没有更多信息（例如上午8点的日期或要遵循的逻辑关系），您将无法回答。几个选项。选择适合您需求的策略。

更新

您在评论中问：


我怎么知道现在UTC是否在X时区的dst中，以便我可以进行相应的调整？


这是datetimeoffset类型可以提供帮助的地方。您不仅要跟踪“ DST是否生效”，还希望跟踪目标时区的精确偏移量，包括可能生效的所有DST。区别是细微的，但是归结为跟踪一个完整的偏移量，而不仅仅是布尔型的是/否。

所以，让我们假装我住在纽约市。选中this site，我们知道EDT于2013年3月10日当地时间2点生效，它将在2013年11月3日当地时间2点回到EST。

因此，我们有以下内容：

UTC                     Local datetimeofffset              
2013-03-10T05:00:00Z    2013-03-10T00:00:00-05:00    
2013-03-10T06:00:00Z    2013-03-10T01:00:00-05:00    
2013-03-10T07:00:00Z    2013-03-10T03:00:00-04:00  <--- transition
2013-03-10T08:00:00Z    2013-03-10T04:00:00-04:00
...
2013-11-03T04:00:00Z    2013-11-03T00:00:00-04:00
2013-11-03T05:00:00Z    2013-11-03T01:00:00-04:00
2013-11-03T06:00:00Z    2013-11-03T01:00:00-05:00  <--- transition
2013-11-03T07:00:00Z    2013-11-03T02:00:00-05:00

现在请注意，如果去除偏移量，则只有单向功能。换句话说，您始终可以为UTC时间确定正确的当地时间，但是除非知道后备过渡期间的偏移量（或者除非您愿意含糊不清），否则您就不能朝其他方向前进。

因此，从UTC到本地时间的算法应如下所示：


从UTC日期时间开始： 2013-11-03T05:30:00Z
应用标准偏移（-5） 2013-11-03T00:30:00-05:00
应用日光偏移量（-4） 2013-11-03T01:30:00-04:00
根据时区规则，哪个有效？

在这种情况下，日光偏移量有效。
您的时区数据应具有此信息。
如果不是，那么您需要重新考虑时区表的来源。



让我们在其他1:30时间再试一次：


从UTC日期时间开始： 2013-11-03T06:30:00Z
应用标准偏移（-5） 2013-11-03T01:30:00-05:00
应用日光偏移量（-4） 2013-11-03T02:30:00-04:00
根据时区规则，哪个有效？

在这种情况下，标准偏移有效。
我们怎么知道？因为-4是夏令时偏移，并且DST应该在当地时间2:00结束。我们与该偏移量有2:30的当地时间，因此只有标准时间在此时区有效。



那么您可以从UTC转换为本地吗？是。总是。

但是您还说过，另一列中的局部值就像 8AM一样。因此，如果它是 1:30AM，那么在后备过渡期间肯定会含糊不清。除了选择一个以外，没有其他方法可以解决此问题。

有时，您可能只想选择其中一个，但有时可能要出错。有时您可能希望让您的用户选择他们感兴趣的两个对象中的哪一个。看到如下所示的对话框并非鲜见：

DAYLIGHT SAVING TIME
We're sorry, but there are two different instances of 1:30 AM on this day.
Which did you mean?

        [1:30 AM Eastern Daylight Time]     [1:30 AM Eastern Standard Time]

...那些是按钮，如果您听不懂。 :)