我在澳大利亚悉尼的位置。我解释的日期将采用英国或澳大利亚日期格式。
请注意以下事项：
这两个时间都以UTC格式从数据库中检索，然后在网络级别计算是否适用+10或+11小时。
在澳大利亚，夏令时（DST）过渡日期逐年变化。过渡日期通常是4月初和10月下旬。
那么网络计算的准确度如何？如果今年过渡日期是几天后（比如说03/04/2010），但是网络计算基于固定日期（比如说01/04/2010），这并不意味着它们之间的日期将是显示时关闭1小时（由于固定计算性质到一个月的特定日期）？
我认为过渡日期不是预先确定的，实际上是向公众宣布的。这个假设是真的吗？
如果不是（这意味着DST日期是预先确定的），我是否可以在Web级别之外进行计算（在 SQL /数据库级别上）？
数据库 SQL Server 2005 ，我使用报告定义语言（RDL）以UTC时间显示字段。如果SQL /数据库级别不是最好的方法，我如何计算+10或+11并相应地格式化时间以显示正确的时间？
谢谢。
答案 0 :(得分：2)
数据库对它来说是一个糟糕的选择：它比c＃或.net更少的信息来解决它。 .net使用注册表，该注册表通过补丁定期更新。 SQL Server必须有一个包含日期范围和偏移的表。
由于调度（航班，火车等），过渡是固定的。 IIRC最近在澳大利亚的一些奥林匹克运动会上发生了一次短时间的变更，这引起了世界各地的混乱。在2007年US changed，但这是事先知道的。
固定后，即使日期不同，也会修复“上周日”类型。
我会将其保留在网络代码中：例如，数据库不知道您的呼叫者在哪里，网站可以解决这个问题。
答案 1 :(得分：1)
问题是谁写了这个应用程序并不完全了解UTC，它的价值以及如何使用它。数据库是dat的正确位置，但系统未按预期使用UTC。
如果您使用UTC，则所有日期算术都应使用UTC。在数据库中。它目前正在使用已保存的UTC，然后在某些情况下进行转换（无论是分区层还是第三层）其他层;其他一些图书馆。一半UTC，另一半。您是否考虑过历史日期，如2010年2月15日至今天的DATEDIFF（）？
这消除了澳大利亚或格陵兰岛对DST的关注。并关注转换实际发生的日期/时间。每个人都在使用格林威治标准时间。
在UTC中以db为单位执行所有日期算术运算。并在本地时区显示结果（仅限），根据用户的不同，它是Web图层。
许多系统完全放弃了最后一步，并且只显示UTC，无论用户的时区如何。
答案 2 :(得分：0)
数据库可以为您处理DST。使用其时区转换功能从您存储日期的任何区域转到您希望为用户获取的任何区域。
MySQL有CONVERT_TZ（），我不知道其他RDBMS有什么。