相关疑难解决方法(0)

当客户端执行时区逻辑时,timestamptz 是首选吗?

我正在将 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 并转换为本地日期时间本身,这仍然是首选吗?

postgresql timestamp datetime

3
推荐指数
1
解决办法
2727
查看次数

标签 统计

datetime ×1

postgresql ×1

timestamp ×1