PostgreSQL now()函数在EF Core与DBeaver中返回结果不一致问题

时间结果不一致的核心原因在于PostgreSQL无时区时间类型的处理逻辑，以及Npgsql（EF Core驱动）与DBeaver在会话时区、类型映射上的差异，具体分析如下：

1. PostgreSQL时间类型转换规则 #

• now()返回的是timestamptz（带时区时间戳），本质存储的是UTC时间，显示时会根据当前会话时区转换为对应本地时间。
• 执行now()::timestamp时，PostgreSQL会将timestamptz转换为当前会话时区下的无时区时间戳——也就是丢弃时区信息，只保留会话时区对应的本地时间数值。

2. DBeaver与EF Core的会话时区差异 #

• DBeaver连接数据库时默认继承数据库时区（Europe/Istanbul，UTC+3），因此now()::timestamp会把UTC时间（如11:00）转换为Europe/Istanbul本地时间（14:00）并直接显示。
• Npgsql驱动则可能因以下原因使用UTC作为会话时区：
  • Windows时区Turkey Standard Time与IANA标准时区Europe/Istanbul的映射异常，导致驱动无法识别本地时区， fallback到UTC。
  • 连接字符串中显式设置了TimeZone=UTC参数。
  • 部分Npgsql版本默认将会话时区设为UTC，而非系统时区。

3. Npgsql与.NET DateTime的映射逻辑 #

PostgreSQL的timestamp（无时区）类型在Npgsql中默认映射为.NET的DateTime，且Kind属性为Unspecified。如果会话时区是UTC，now()::timestamp返回的就是UTC时间数值（11:00），直接读取后就会得到与DBeaver相差3小时的结果。

解决方法 #

方法1：修正连接字符串的时区设置 #

在连接字符串中显式指定时区为Europe/Istanbul，确保会话时区与数据库一致：

Server=你的服务器地址;Port=5432;Database=你的数据库;User Id=账号;Password=密码;TimeZone=Europe/Istanbul

方法2：改用带时区的时间类型查询 #

避免使用无时区的timestamp，直接查询timestamptz类型，让Npgsql正确处理时区转换：

var sql = @"select now()"; // 返回timestamptz类型
using IDbConnection con = _context.Database.GetDbConnection();
var result = (await con.QueryAsync<SqlResponse>(sql)).ToList();

同时推荐将模型属性改为DateTimeOffset（明确带时区）：

public class SqlResponse
{
    public DateTimeOffset Now { get; set; }
}

如果保留DateTime类型，Npgsql会返回Kind=Utc的实例，可通过ToLocalTime()转换为本地时区时间。

方法3：SQL中显式指定时区转换 #

如果必须使用timestamp类型，可在SQL中强制指定转换为目标时区的时间：

select now() at time zone 'Europe/Istanbul'::timestamp

内容的提问来源于stack exchange，提问作者Tolga Cakir