Is your enhancement related to a problem? Please describe
When running KubernetesMockServer in crud mode it depends directly on the system time. For example, in junit/kubernetes-server-mock/src/main/java/io/fabric8/kubernetes/client/server/mock/crud/PostHandler.java at line 88-89 we set the creationTimestamp of a resource:
resource.getMetadata().setCreationTimestamp(
ZonedDateTime.now(ZoneOffset.UTC).truncatedTo(ChronoUnit.SECONDS).format(DateTimeFormatter.ISO_INSTANT));
As you can see this depends directly on the system time, which you have little control over in your tests.
This is just an example, but this direct dependency on the system time happens on more occasions.
Describe the solution you'd like
It would be great if we could inject an instance of java.time.Clock somehow and use that to generate timestamps so that we have total control over it in our tests instead of depending on the system time.
I think this change shouldn't be too complex. I am open to contributing it myself if others agree.
Describe alternatives you've considered
No response
Additional context
No response
Is your enhancement related to a problem? Please describe
When running
KubernetesMockServerin crud mode it depends directly on the system time. For example, injunit/kubernetes-server-mock/src/main/java/io/fabric8/kubernetes/client/server/mock/crud/PostHandler.javaat line 88-89 we set thecreationTimestampof a resource:As you can see this depends directly on the system time, which you have little control over in your tests.
This is just an example, but this direct dependency on the system time happens on more occasions.
Describe the solution you'd like
It would be great if we could inject an instance of
java.time.Clocksomehow and use that to generate timestamps so that we have total control over it in our tests instead of depending on the system time.I think this change shouldn't be too complex. I am open to contributing it myself if others agree.
Describe alternatives you've considered
No response
Additional context
No response