1

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

请注意以下事项:

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

这两个时间都以 UTC 格式从数据库中检索,然后在 Web 级别计算+10 或 +11 小时是否适用。

在澳大利亚,夏令时 (DST) 过渡日期每年都不同。过渡日期通常是四月初和十月下旬。

那么 Web 计算的准确性如何呢?如果今年的过渡日期在几天后(例如 03/04/2010),但网络计算基于固定日期(例如 01/04/2010),这是否意味着两者之间的日子将是显示时关闭 1 小时(由于每月特定日期的固定计算性质)?

我相信过渡日期不是预先确定的,实际上是向公众宣布的。这个假设是真的吗?

如果不是(这意味着 DST 日期是预先确定的),我可以在 Web 级别之外(在SQL/数据库级别)进行计算吗?

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

谢谢你。

4

3 回答 3

2

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

由于日程安排(航班、火车等),转换是固定的。IIRC它最近在澳大利亚的一些奥运会上只在短时间内改变了一次,它在世界范围内引起了混乱。2007 年美国发生了变化,但这是事先就知道的。

通过固定,即使日期变化,它也是固定的“最后一个星期日”类型。

我会把它留在网络代码中:例如,数据库不知道你的调用者在哪里,网站可以解决它。

于 2010-11-10T05:10:33.153 回答
1

问题是编写此应用程序的人不太了解 UTC、它的价值以及如何使用它。数据库是 dat 的正确位置,但系统未按预期使用 UTC。

如果您使用 UTC,那么您所有的日期算术都应该使用 UTC。在数据库中。它当前正在使用保存的 UTC,然后在某些(无论是第二层还是第三层)其他层进行转换;其他一些图书馆。一半 UTC,一半其他。您是否考虑过历史日期,例如 2010 年 2 月 15 日到今天之间的 DATEDIFF() 是什么?

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

用 UTC 在数据库中做所有的日期算术。并(仅)在本地时区显示结果,正如您所拥有的那样,它是基于用户的 web 层。

许多系统完全放弃了最后一步,并且仅以 UTC 显示,而与用户所在的时区无关。

于 2010-11-11T08:22:28.610 回答
0

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

MySQL 有 CONVERT_TZ(),我不知道其他 RDBMS 有什么。

于 2010-11-10T04:28:08.927 回答