Clone restore from GS fails due to incorrect datetime format

• Which image of the operator are you using?
• registry.opensource.zalan.do/acid/postgres-operator:v1.9.0
• Spilo Image: ghcr.io/zalando/spilo-15:2.1-p9
• Where do you run it - cloud or metal? Kubernetes or OpenShift?
• GCP
• Are you running Postgres Operator in production? [yes | no]
• yes
• Type of issue? [Bug report, question, feature request, etc.]
• Bug report, question

We tried to restore a pg cluster from GS using the clone spec in the cluster manifest.

apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
  name: graph-engine-db
spec:
  teamId: "graph"
  numberOfInstances: 1
  volume:
    size: 10Gi
  clone:
    uid: "a728d3bc-0b15-4436-8733-4cbc00d1258c"
    cluster: "graph-engine-db"
    timestamp: "2023-03-23T08:00:00+01:00"
  postgresql:
    version: "13"

The restore script /scripts/clone_with_wale.py fails however with following error:

TypeError: can't compare offset-naive and offset-aware datetimes

(see https://gist.github.com/0x1d/41dfadfc34ce2a99ce781fa4dfe12c5a for full error message).

I've checked the documentation, and timestamp should be in the correct format.
When I change clone_with_wale.py and fix the broken line like this:

if last_modified.timestamp() < recovery_target_time.timestamp():

the clone works, but the following commands (maybe_pg_upgrade) fails and leaves the instance in a broken state.

Am I missing something configuration wise or is it a bug with the clone_with_wale.py script?

Start with /scripts/clone_with_wale.py and the provided clone spec, then reproduce the GS restore using the listed operator and Spilo images. Check the datetime comparison failure and follow the subsequent maybe_pg_upgrade failure; done means the documented timestamp format restores the cluster without leaving the instance broken.