nit: k8s' duration format is documented as Go's time.Duration. Timeouts in our components (visibilityTimeout, timeout) are also based on Go's duration format. Some other common K8s components that I was able to check also use time.Duration format. It feels a bit weird to have the same attribute use different input formats inside the same project (even the same "visibilityTimeout" parameter). Why did you decide to switch to ISO format? Is it because of OpenAPI 3.0 spec? Maybe we could do something to make it consistent across the components?

nit: k8s' duration format is documented as Go's time.Duration. Timeouts in our components (visibilityTimeout, timeout) are also based on Go's duration format. Some other common K8s components that I was able to check also use time.Duration format. It feels a bit weird to have the same attribute use different input formats inside the same project (even the same "visibilityTimeout" parameter). Why did you decide to switch to ISO format? Is it because of OpenAPI 3.0 spec? Maybe we could do something to make it consistent across the components?

I agree on having something consistent across the components but go time is language specific, while ISO is a standard.

Knative uses ISO for durations too: https://knative.dev/docs/eventing/event-delivery/#configuring-subscription-event-delivery
Maybe we should move other components to ISO? We already have brokers using ISO.

Go time format is natively supported by k8s, so I don't see why we can't keep using it. Personally, I'm not a fan of the ISO format because it's not intuitive, but having the same attributes declared in different formats is even worse than that. Hence, if you think that switching to the ISO is essential and worth introducing breaking change, then go for it. Hopefully, we will not follow Knative's specification style in the future.

Ok, no problem, I'll revert it to go time and then we can discuss what standard we should use

That works for me, thank you. I noticed that the core k8s components use <param>Seconds attribute name to avoid any confusion in formats. Maybe we could use a similar approach. The only concern is backward compatibility for SQS source spec.

@FranBarrera any chance we can get some better documentation for the attribute to appear in the CRD?