[Bug]: Timezone of CNPG Cluster Not Respected for ScheduledBackup timing

[chrisblatt]

Is there an existing issue already for this bug?

• [x] I have searched for an existing issue, and could not find anything. I believe this is a new bug.

I have read the troubleshooting guide

• [x] I have read the troubleshooting guide and I think this is a new bug.

I am running a supported version of CloudNativePG

• [x] I have read the troubleshooting guide and I think this is a new bug.

Contact Details

No response

Version

1.27 (latest patch)

What version of Kubernetes are you using?

1.31

What is your Kubernetes environment?

Other

How did you install the operator?

Helm

What happened?

• I installed the operator and create a cluster, never specified a timezone
• created schedulebackup and noticed that they ran nightly at UTC time not midnight EST
• Updated the Cluster CRD to specific postgresql paramter for timezone
  • Confirmed in db that timezone update was recognized
• Waited for next backup but it still ran at UTC time
• Set the env var TZ to EST, but still see in controller logs that backup was scheduled for UTC

{"level":"info","ts":"2025-12-08T15:50:28.722630646Z","msg":"Next backup schedule","controller":"scheduled-backup","controllerGroup":"postgresql.cnpg.io","controllerKind":"ScheduledBackup","ScheduledBackup":{"name":"backup-platform-db-nightly","namespace":"my-ns"},"namespace":"my-ns","name":"backup-platform-db-nightly","reconcileID":"82bab848-e352-474a-a4b1-5e4cea98014b","next":"2025-12-09T11:50:00Z"}

Cluster resource

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: platform-db
spec:
  backup:
    volumeSnapshot:
      className: my-snapclass
  enableSuperuserAccess: true
  env:
  - name: TZ
    value: US/Eastern
  imageName: ghcr.io/cloudnative-pg/postgresql:16.2-bookworm
  instances: 3
  postgresql:
    parameters:
      timezone: US/Eastern
  primaryUpdateMethod: switchover
  primaryUpdateStrategy: unsupervised
  storage:
    size: 100Gi
    storageClass: my-sc
  superuserSecret:
    name: db-admin
  walStorage:
    size: 10Gi
    storageClass: my-sc

Relevant log output

{"level":"info","ts":"2025-12-08T15:50:28.722630646Z","msg":"Next backup schedule","controller":"scheduled-backup","controllerGroup":"postgresql.cnpg.io","controllerKind":"ScheduledBackup","ScheduledBackup":{"name":"backup-platform-db-nightly","namespace":"my-ns"},"namespace":"my-ns","name":"backup-platform-db-nightly","reconcileID":"82bab848-e352-474a-a4b1-5e4cea98014b","next":"2025-12-09T11:50:00Z"}

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

[dosubot[bot]]

Hi @chrisblatt! I'm Dosu and I’m helping the cloudnative-pg team.

ScheduledBackup in CloudNativePG always uses UTC for scheduling, regardless of the PostgreSQL cluster's timezone or the TZ environment variable. This is by design: the controller calculates backup times using the system time of the controller pod (typically UTC in Kubernetes), and there is no code that reads the cluster's timezone or the TZ variable for scheduling. The PostgreSQL timezone parameter only affects database sessions, not backup scheduling logic.

There is an open feature request to add timezone support to ScheduledBackup (e.g., a .spec.timeZone field), but this is not yet implemented. For now, if you want backups to run at a specific local time, you need to adjust your cron schedule to match the equivalent UTC time. If you need timestamps in a different timezone for reporting, you'll need to convert them externally after retrieving them from the API or logs.

References:

• Feature request for ScheduledBackup timezone support
• Backup timestamps and scheduling always in UTC
• Controller logic uses UTC/system time, not cluster or DB timezone

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[chrisblatt]

That feature request is closed as not planned.

I know this might seem like a small annoyance but when you have many (10s or 100s) of clusters that need backups scheduled in their respective timezones, this turns into a headache and error prone activity to have to base everything off of UTC instead of a configurable timezone.