Docker容器中运行PostgreSQL：自定义now()返回的当前时间

核心结论 #

修改容器系统时间确实能实现需求，但存在不少限制；更推荐用PostgreSQL自定义函数的方式，更安全且不影响容器其他功能。

修改容器系统时间的可行性 #

PostgreSQL的NOW()、CURRENT_TIMESTAMP这类函数直接读取容器的系统时间，所以修改容器时间就能让这些函数返回指定值。但要注意几个关键点：

• Docker默认和宿主共享时钟命名空间，直接改容器时间会同步影响宿主时间，必须开启权限隔离：
  启动容器时添加--cap-add SYS_TIME参数（权限范围比--privileged更小），同时在启动命令里先设置时间再启动数据库：

  docker run --cap-add SYS_TIME -d timescale/timescaledb:latest-pg15 sh -c "date -s '2010-12-01 23:00:44' && postgres"
  

  如果用Docker Compose，配置如下：

  services:
    timescaledb:
      image: timescale/timescaledb:latest-pg15
      cap_add:
        - SYS_TIME
      command: ["sh", "-c", "date -s '2010-12-01 23:00:44' && postgres"]
  

• 这种方法的弊端：容器重启后必须重新执行时间设置；容器内所有进程都会使用这个修改后的时间，可能打乱日志时间、定时任务等其他功能。

更安全的替代方案：自定义时间函数 #

不想改动容器系统时间的话，直接在PostgreSQL里自定义函数替代NOW()：

1. 创建固定时间函数：
   连接数据库后执行以下SQL：

   CREATE OR REPLACE FUNCTION fixed_now() RETURNS timestamp with time zone AS $$
   SELECT '2010-12-01 23:00:44.851242 +00:00'::timestamp with time zone;
   $$ LANGUAGE sql STABLE;
   

   测试时用SELECT fixed_now()代替SELECT NOW()即可。
2. 重写原生NOW()函数（仅测试环境使用）：
   如果API里硬编码了NOW()，可以直接重写这个函数（绝对不要在生产环境这么做）：

   CREATE OR REPLACE FUNCTION now() RETURNS timestamp with time zone AS $$
   SELECT '2010-12-01 23:00:44.851242 +00:00'::timestamp with time zone;
   $$ LANGUAGE sql STABLE;
   

   这种方式只影响数据库内部的时间返回，容器系统时间完全不受影响，重启容器后只要函数存在就生效，非常适合API测试场景。

总结 #

• 修改容器系统时间可行，但权限要求高且影响范围大，仅适合简单测试场景。
• 自定义函数的方式更可控、安全，是API测试的首选方案。

内容的提问来源于stack exchange，提问作者Scott Clark