我的本地开发服务器在中东，但我的生产服务器在英国。
我需要在他们的时区向用户显示日期。例如，如果用户在沙特阿拉伯，那么我需要根据沙特阿拉伯格式显示时间。
我应该创建一个名为 TimeZone 的新数据库表并以 UTC 格式保存时间吗？
我目前使用以下方法从 UTC 日期时间获取本地日期时间：
SET @offset = DateDiff(minute, GetUTCDate(), GetDate())
SET @localDateTime = DateAdd(minute, @offset, @utcDateTime)
我的问题是，如果夏令时发生在GetUTCDate()和之间@utcDateTime，@localDateTime最终会休息一个小时。
是否有一种简单的方法可以将非当前日期的日期从 UTC 转换为当地时间？
我使用的是 SQL Server 2005
我正在研究 PostgreSQL 数据库设计，我想知道如何最好地存储时间戳。
不同时区的用户将使用数据库执行所有 CRUD 功能。
我查看了 2 个选项：
timestamp NOT NULL DEFAULT (now() AT TIME ZONE 'UTC')
bigint NOT NULL DEFAULT
因为timestamp我会发送一个字符串来表示 INSERT 时刻的确切（UTC）时间戳。
因为bigint我会存储完全相同的东西，但以数字格式存储。（时区问题是在将毫秒移交给服务器之前处理的，因此总是以 UTC 为单位的毫秒。）
存储 a 的一个主要优点bigint可能是它更容易存储和检索，因为传递正确格式的时间戳比简单的数字（自 Unix Epoc 以来的毫秒）更复杂。
我的问题是哪种方法可以实现最灵活的设计，以及每种方法可能存在哪些缺陷。
当我运行以下命令时，出现错误，但是我的一个脚本需要它。
SET time_zone = 'UTC';
ERROR 1298 (HY000): Unknown or incorrect time zone: 'UTC'
我有一个运行在服务器上的 PostgreSQL 数据库，它的时区设置为印度的时区（即 UTC +5:30）
我在一个表中有一些数据，它是这样创建的：
CREATE TABLE "CLOUDDATA"
(
"CD_Tm_Obs" timestamp without time zone,
"CD_Avg_Cloud" double precision
)
我想查询数据并获取特定时间的值。我的输入将是 Unix 时间戳（即 1970 年 1 月 1 日的秒数）
转换UNIX时间时间戳我发现的唯一方法是这样的：
select to_timestamp(TRUNC(CAST(1395036000 AS bigint)))。但这会创建一个带时区的时间戳。我的数据在 中timestamp without time zone，所以我没有得到任何结果。
如何在没有时区的情况下将 unix 时间转换为 PostgreSQL 的 Timstamp？
SQL Server 2016AT TIME ZONE似乎是不确定的。但是，我一直无法找到正式说明这一点或对其背后的推理给出理由的文档。
为什么是AT TIME ZONE不确定的？
执行：
CREATE TABLE Test (
LegacyTimestamp DATETIME,
Timestamp AS LegacyTimestamp AT TIME ZONE 'Eastern Standard Time' PERSISTED
);
返回以下错误：
Msg 4936, Level 16, State 1, Line 1
Computed column 'Timestamp' in table 'Test' cannot be persisted because the column is non-deterministic.
在 Postgres 9.5 中，我很惊讶地看到在尝试 year 0001（没有 year zero 0000）时看到的结果。
-07:52:58？一些示例代码。请注意，我混合使用了TIMESTAMP WITH TIME ZONE和TIMESTAMP WITHOUT TIME ZONE，所以请仔细阅读。
SET TIME ZONE 'America/Los_Angeles' ;
SELECT (TIMESTAMP WITH TIME ZONE '2015-01-01 00:00:00.0',
TIMESTAMP WITH TIME ZONE '0001-01-01 00:00:00.0Z',
TIMESTAMP WITHOUT TIME ZONE '0001-01-01 00:00:00.0Z') ;
("2015-01-01 00:00:00-08","0001-12-31 16:07:02-07:52:58 BC","0001-01-01 00:00:00")
我对第二个值感到惊讶：0001-12-31 16:07:02-07:52:58 BC. 我知道我们必须America/Los_Angeles在 UTC后八小时后退八小时，偏移量为-08:00. 但不是-08:00偏移量是-07:52:58. 为什么？
在 UTC 下输入数据时没有这样的问题。
SET TIME ZONE 'UTC' …我们开始设计数据集市/仓库的构建块，我们需要能够支持所有时区（我们的客户来自世界各地）。从在线（和书籍）阅读讨论来看，一个常见的解决方案似乎是在事实表中具有单独的日期和时间维度以及时间戳。
但是，我很难回答的问题是，考虑到我的动态时区要求，日期和时间维度实际上对我有什么好处？时间维度更有意义，但我很难处理日期维度。日期维度的一般设计方法通常包括日期名称、星期几、月份名称等属性。我遇到的所有问题是 UTC 时间 2013 年 12 月 31 日星期二晚上 11:00 是星期三, 2014 年 1 月 1 日，在 UTC+2 之后的所有时区。
因此，如果我必须对每个查询（和报告）进行所有这些时区转换，那么拥有和存储这些我可能永远不会使用（似乎）的属性有什么意义？有些人建议为每个时区设置事实行，但这对我来说似乎很荒谬。我们需要能够每月存储数百万条记录。
其他人建议有一个时区桥接表，虽然有一定的意义，但它似乎也需要额外的复杂性和额外的连接来完成我的客户端应用程序和报告应该能够轻松地从日期中找出的东西（报告将主要基于网络那里有无数的库可以帮助转换、显示和格式化日期）。
我唯一能想到的是按日期和小时分组的简便性和可能的性能，但是按日期部分分组的做法有多糟糕（我们正在使用 MS SQL，但我们将查询数百万行），或者我们应该考虑只是非常简单的日期和时间维度，大多数情况下不超过小时、日、月和年数字，因为大多数文字（例如星期一）在时区发挥作用时没有多大意义？
我在回答这个stackoverflow问题时发现了奇怪的结果：
select * from pg_timezone_names where name = 'Europe/Berlin' ;
name | abbrev | utc_offset | is_dst
---------------+--------+------------+--------
Europe/Berlin | CET | 01:00:00 | f
和下一个查询
select id,
timestampwithtimezone,
timestampwithtimezone at time zone 'Europe/Berlin' as berlin,
timestampwithtimezone at time zone 'CET' as cet
from data ;
id | timestampwithtimezone | berlin | cet
-----+------------------------+---------------------+---------------------
205 | 2012-10-28 01:30:00+02 | 2012-10-28 01:30:00 | 2012-10-28 00:30:00
204 | 2012-10-28 02:00:00+02 | 2012-10-28 02:00:00 | 2012-10-28 01:00:00
203 | 2012-10-28 02:30:00+02 …我有一个在 Postgres 上运行的大小合适（约 50k 行）的时间序列数据库，还有一些其他结构化数据（在另一个数据库实例中）要小得多。
愚蠢的是，当我最初设计这个东西时，我把所有的字段都作为TIMESTAMP WITHOUT TIME ZONE，现在我用恼人的时区相关的错误来支付它。我希望一切都是明确的，所以想将字段转换为TIMESTAMP WITH TIME ZONE. 我意识到这不会存储额外的信息，并且我所有的时间戳都已经在 UTC 中，所以迁移应该是微不足道的，但我想知道是否有任何复杂的事情/潜在的绊倒块会证明有问题（这是一个生产客户依赖它的数据库）？