Support for java.time.Duration

[cowwoc]

Is your enhancement related to a problem? Please describe

Having to store and specify durations using two separate constants is a bit of a pain.

Describe the solution you'd like

Given that the API requires JDK 11 and java.util.Duration was added in JDK 8, consider adding methods that take a Duration instead of (or alongside) the methods that currently take a TimeUnit. You can convert from one to the other using TimeUnit.convert() under the hood for backwards compatibility.

Describe alternatives you've considered

No response

Additional context

No response

[rohanKanojia]

@cowwoc : we have a Duration class that accepts java.util.Duration in constructor. Does it help your use case?

[cowwoc]

I don't think so. I'm talking about about able to pass Durations into functions like waitUntilCondition().

[manusa]

Currently (and unfortunately), the time handling is quite messy in the client.

Depending on the module, we handle timestamps as Strings, MicroTime, Duration, and more.
It's very inconsistent and probably because along the years, upstream Kubernetes introduced additional time types, and our local models and extensions processors were implemented manually by different people.

The goal would be to unify all of our time formats to the Java standards.
This wasn't done in the scope of v7.0.0 to minimize the amount of breakages and allow for a smoother transition to this version for our users.

For v8, this is definitely one of the things we want to achieve.
Probably by providing backwards compatible getters and setters to also prevent big breaking changes.