在SQL/数据库级别上计算夏令时(DST)

Question

我的位置在澳大利亚悉尼，。我解释的日期将是英国或澳大利亚的日期格式。

观察以下情况：

• 2010-04-15 04:30:00.000 => 15/04/201014:30 EST 14:30(英国日期格式-加10小时)
• 2010- 11 -05 :00:00.000 => 05/11/201012:00 EST (英国日期格式-加11小时)

这两次都以UTC格式从数据库中检索，然后在级别上计算，无论是+10小时还是+11小时。

在澳大利亚，夏令储蓄时间(DST)的转换日期逐年变化。过渡日期通常是4月初和10月底。

那么，Web计算会有多精确呢？如果今年的过渡日期是几天后(比如03/04/2010)，但是Web计算是基于一个固定日期(例如01/04/2010)，那么这不意味着在显示之间的天数将为1小时(因为固定的计算性质要到一个月的某一天)吗？

我相信过渡日期不是预先决定的，而是公开宣布的.这个假设是真的吗？

如果没有(这意味着DST日期是预先确定的)，我是否能够在网络级别之外(在SQL/数据库级别上)进行计算？

数据库是 Server 2005，我使用报表定义语言(RDL)在UTC时间显示字段。如果SQL/数据库级别不是最好的方法，我如何计算出+10或+11并相应地格式化时间以显示正确的时间？

谢谢。

Answer 1

数据库对它来说是个糟糕的选择:它比c#或.net有更少的信息来计算它。.net使用由补丁定期更新的注册表。Server必须有一个具有日期范围和偏移量的表。

过渡是固定的，因为日程安排(航班，火车，什么的)。最近，在澳大利亚一些奥运会上，IIRC只在短时间内改变了一次，并在世界范围内引起了混乱。在2007年的我们变了，但这是事先知道。

通过固定，它是“上星期日”类型固定，即使日期变化。

我会把它放在web代码中: DB不知道您的调用方在哪里--例如，网站可以计算出它。

Answer 2

问题是，无论是谁编写了这个应用程序，都不太了解UTC，它的价值，以及如何使用它。数据库是dat的正确位置，但系统没有按预期使用UTC。

如果您使用UTC，那么您的所有日期算法都应该使用UTC。在数据库里。它目前正在使用保存的UTC，然后在另一层(无论是第二层还是第三层)进行转换；其他库。一半是世界协调时，另一半是别的东西。您是否考虑过历史日期，如2010年2月15日至今天之间的DATEDIFF()？

这就消除了澳大利亚或格陵兰对DST的关注，并关注了转换的实际发生日期/时间。每个人都在使用格林威治标准时间在那个特定的日子。

以协调世界时为单位，在db中执行所有日期算法。并将结果(仅)显示在本地时区中，而本地时区是基于用户的web层。

许多系统已经完全放弃了最后一步，只在UTC中显示，而不管用户的时区如何。

Answer 3

数据库可以为您处理DST。使用它的时区转换函数可以从存储日期的任何区域转到您想为用户获取的任何区域。

MySQL有CONVERT_TZ()，我不知道其他关系数据库管理系统有什么。