❗ By default, the pull request is configured to backport to all release branches.

• To stop backporting this pr, remove the label: backport-requested ◀️ or add the label 'do not backport'
• To stop backporting this pr to a certain release branch, remove the specific branch label: release-x.y

Was looking at this, and have a concern.

The code still says RFC3339. See cluster_types.go

type RecoveryTarget struct {
	<------->
	// The target time as a timestamp in the RFC3339 standard
	// +optional
	TargetTime string `json:"targetTime,omitempty"`

And in the machinery repo, in time.go, the below function takes RFC3339, RFC3339Micro, or timestamp

func ConvertToPostgresFormat(timestamp string) string {

So, if the documentation is indeed wrong, and only timestamps are to be allowed, shouldn't the code change too?
The doc and code are definitely out of sync.

And, since @mnencia approved previously: I'd like your take on this.
There is a problem here in the code in that we have asymmetry.
The webhook admits the targetTime formated in as in the documentation ("2023-07-06T08:00:39", which is not valid RFC3339 because of the missing Z), but the processing will not generate a proper Postgres timestamp.

The webhook uses func ParseTargetTime at /cloudnative-pg/machinery@v0.3.1/pkg/types/time.go, which specifically admits the above format.

BUT, in func ConvertToPostgresFormat /cloudnative-pg/machinery@v0.3.1/pkg/postgres/time/time.go, that format is passed through, and it is NOT a valid Postgres format, whereas RFC3339 and RFC3339Micro are regenerated into Postgres format.

Why do we have the special format allowed in ParseTargetTime?

After your comments @jsilvela, I tried again an unit test to confirm there is an issue, event with Z at the end of timestamp.
Here are steps :

First create a cluster with backup section using plugin :

---
apiVersion: v1
kind: Secret
metadata:
  name: minio-creds
type: Opaque
data:
  ACCESS_KEY_ID: bWluaW9hZG1pbg==
  ACCESS_REGION: ZnItcGFy
  ACCESS_SECRET_KEY: bWluaW9hZG1pbg==
---
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-alice
spec:
  imageName: ghcr.io/cloudnative-pg/postgresql:17.5
  instances: 1
  storage:
    size: 1Gi
  # Backup properties
  plugins:
  - name: barman-cloud.cloudnative-pg.io
    isWALArchiver: true
    parameters:
      barmanObjectName: minio-store
---
apiVersion: barmancloud.cnpg.io/v1
kind: ObjectStore
metadata:
  name: minio-store
spec:
  configuration:
    destinationPath: s3://demo/pierrick
    endpointURL: http://172.18.0.3:9000
    s3Credentials:
      accessKeyId:
        name: minio-creds
        key: ACCESS_KEY_ID
      secretAccessKey:
        name: minio-creds
        key: ACCESS_SECRET_KEY
      region:
        name: minio-creds
        key: ACCESS_REGION

Create backup
`kubectl cnpg backup cluster-alice --method=plugin --plugin-name=barman-cloud.cloudnative-pg.io

k describe backups.postgresql.cnpg.io cluster-alice-20251027172908
...
  Plugin Metadata:
    Cluster UID:   def9ae28-9aea-4a99-833e-e05a61c03901
    Display Name:  BarmanCloudInstance
    Name:          barman-cloud.cloudnative-pg.io
    Plugin Name:   barman-cloud.cloudnative-pg.io
    Timeline:      1
    Version:       0.7.0
  Started At:      2025-10-27T16:29:09Z
  Stopped At:      2025-10-27T16:29:10Z
Events:
  Type    Reason     Age   From                   Message
  ----    ------     ----  ----                   -------
  Normal  Starting   10m   cloudnative-pg-backup  Starting backup for cluster cluster-alice
  Normal  Starting   10m   local-webserver        Backup started
  Normal  Completed  10m   local-webserver        Backup completed

Create a cluster with bootstrap restore method

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-bob
spec:
  imageName: ghcr.io/cloudnative-pg/postgresql:17.5
  instances: 1
  storage:
    size: 1Gi
  bootstrap:
    recovery:
      source: backup-cluster-alice
        targetTime: "2025-10-27T16:30:10Z"
  externalClusters:
    - name: backup-cluster-alice
      plugin:
        name: barman-cloud.cloudnative-pg.io
        parameters:
          barmanObjectName: minio-store
          serverName: cluster-alice

The bob cluster start with a recovery Pod :

{
  "level": "info",
  "ts": "2025-10-27T16:32:59.56105952Z",
  "msg": "Starting webserver",
  "logging_pod": "cluster-bob-1-full-recovery",
  "address": "localhost:8010",
  "hasTLS": false
}

... but get this error :

{
  "level": "info",
  "ts": "2025-10-27T16:33:03.221008034Z",
  "msg": "Starting up instance",
  "logging_pod": "cluster-bob-1-full-recovery",
  "pgdata": "/var/lib/postgresql/data/pgdata",
  "options": [
    "start",
    "-w",
    "-D",
    "/var/lib/postgresql/data/pgdata",
    "-o",
    "-c port=5432 -c unix_socket_directories=/controller/run",
    "-t 40000000",
    "-o",
    "-c listen_addresses='127.0.0.1'"
  ]
}
{
  "level": "info",
  "ts": "2025-10-27T16:33:03.238768322Z",
  "logger": "pg_ctl",
  "msg": "waiting for server to start....2025-10-27 16:33:03.238 UTC [46] LOG:  invalid value for parameter \"recovery_target_time\": \"2025-10-27 16:30:10.000000Z\"",
  "pipe": "stdout",
  "logging_pod": "cluster-bob-1-full-recovery"
}
{
  "level": "info",
  "ts": "2025-10-27T16:33:03.238788644Z",
  "logger": "pg_ctl",
  "msg": "2025-10-27 16:33:03.238 UTC [46] FATAL:  configuration file \"/var/lib/postgresql/data/pgdata/custom.conf\" contains errors",
  "pipe": "stdout",
  "logging_pod": "cluster-bob-1-full-recovery"
}
{
  "level": "info",
  "ts": "2025-10-27T16:33:03.33110249Z",
  "logger": "pg_ctl",
  "msg": "pg_ctl: could not start server",
  "pipe": "stderr",
  "logging_pod": "cluster-bob-1-full-recovery"
}

LOG: invalid value for parameter \"recovery_target_time\": \"2025-10-27 16:30:10.000000Z\""

@pchovelon huh! The conversion from RFC3339 to postgres was partial. I was expecting full or pass-through, from the code ... I'll try to zero on this tomorrow.

OK, @pchovelon , pretty stumped.
The conversion above was not partial, but complete and correct. The final Z for UTC is in both the RFC3339 format, and ISO 8601, which Postgres is compatible with.

And, the string you show is a valid Postgres timestamp:

select timestamp with time zone  '2025-10-27 16:30:10.000000Z';
      timestamptz       
------------------------
 2025-10-27 16:30:10+00

So, may be a specific issue with recovery_target_time.
I'm getting more confused with time (pun intended).

According to postgres, if it's valid as a timestamp with time zone, it ought to work. 🤔

The value of this parameter is a time stamp in the same format accepted by the timestamp with time zone data type

https://www.postgresql.org/docs/17/runtime-config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY-TARGET

Howdy @pchovelon . I've made some experiments.
The problem is with times formatted with a trailing Z (those in UTC zone).
In the Postgres doc for recovery_target_time you can see

The value of this parameter is a time stamp in the same format accepted by the timestamp with time zone data type, except that you cannot use a time zone abbreviation

If the RFC3339 timestamp input in the manifest is instead converted to use +00 for UTC, instead of Z, PITR works fine.

Your doc fix, IMO, while relevant, should be changed:

• on one hand, if we say we accept RFC3339 in the manifest, let's make it work rather than give up on it.
• on the other hand, the docstrings in the code make it seem like ONLY RFC3339 is supported, which is not accurate.

I've opened cloudnative-pg/machinery#167 to fix the conversion function.
IMO while the code is easy and I'll get it out today, this requires pondering from the maintainers.

Howdy @pchovelon . I've made some experiments.

Great, thank you @jsilvela . Running after time here ... I try to answer asap.

/test

@armru, here's the link to the E2E on CNPG workflow run: https://github.com/cloudnative-pg/cloudnative-pg/actions/runs/20577814711