当客户端执行时区逻辑时，timestamptz 是首选吗？

Question

我正在将 Web 应用程序从 SqlServer 迁移到 PostgreSQL，并且我正在尝试找出要替换的类型datetime2。

一般的建议似乎是总是使用timestamptz，以及从不使用timestamp。给出的原因往往是时间戳和timestamptz存储相同（因此没有性能损失）并timestamptz自动转换为连接的时区。在 Rails 和 PostgreSQL 中完全忽略时区 | 堆栈溢出

不幸的是，我的旧版 .NET 代码库与日期时间非常不一致，我们通常以 UTC 进行渲染，而不管用户时区如何。最近的代码一直在使用 NodaTime 及其Instant类，但我们很少需要处理时间并且仅显示日期已经“足够接近”。然而，我对正确使用 NodaTime 的理解是尽可能晚地将 转换Instant为，而不是在数据库中。LocalDateTime

除此之外，我不完全确定 Postgres 如何知道“当前用户”的正确时区。我知道您可以专门将时区设置为会话参数SET TIME ZONE 'UTC';，您是否希望为每个连接执行此操作以适合“当前用户”？如果是这样，每当从连接池检索连接时都会重置它吗？我还看到 Npgsql 能够为连接字符串设置时区，如果是针对每个用户，这可能是不合适的？

所有这些使我认为最好的选择是用于timestamp所有日期时间，并使用应用程序逻辑转换为本地日期时间。我想另一个选择是用于timestamptz所有日期时间，强制连接在连接字符串中使用 UTC，并使用应用程序逻辑转换为本地日期时间。但是我担心 Postgres 会在 UTC 和 UTC 之间进行无操作转换时执行额外的工作。

TLDR：timestamptz如果应用程序始终插入/读取 UTC 并转换为本地日期时间本身，这仍然是首选吗？

Answer 1

timestamptz如果应用程序始终插入/读取 UTC 并转换为本地日期时间本身，仍然是首选吗？

嗯，不。然后使用起来会稍微简单/更快timestamp。

但“应用程序”是访问数据库的唯一客户端吗？它会在数据库的生命周期中保持这种状态吗？

如果仍有疑问，我仍然会使用timestamptz，这是安全的选择。您已经找到了我的相关答案，所以我建议作为基本信息的参考：

• 在 Rails 和 PostgreSQL 中完全忽略时区

另外，timestamptz字面上是 Postgres 中“日期/时间类型”中的“首选”类型（标记typeispreferred为pg_type），这可能会有所不同，但可能不会对您的特定问题产生影响，即使问题标题几乎听起来像是您可能会要求的那。有关的：

• 在 PostgreSQL 中生成两个日期之间的时间序列