Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistencies with mock server timestamps #6632

Closed
Hoferl opened this issue Nov 19, 2024 · 4 comments · Fixed by #6651
Closed

Inconsistencies with mock server timestamps #6632

Hoferl opened this issue Nov 19, 2024 · 4 comments · Fixed by #6651
Assignees
Labels
Milestone

Comments

@Hoferl
Copy link

Hoferl commented Nov 19, 2024

Is your enhancement related to a problem? Please describe

I am using the KubernetesMockServer for testing my K8s Operator which uses the deletionTimestamp in the metadata when deleting a resource. The problem is that I expect this timestamp to be formatted with a trailing timezone for parsing, but the mock server returns it in a different format. The creationTimestamp on the other hand is formatted as expected.

Example:
deletionTimestamp = "2024-11-19T15:18:14.048045500"
creationTimestamp = "2024-11-19T14:18:11.071782Z"

I assume both fields are set and managed by the mock server, is this different behavior intended?
Setting the Timezone in my Java Test code to UTC resolves the 1 hour difference but does not add a "Z".

Describe the solution you'd like

I would expect the same formatting for both timestamps. Ideally it would be in the ISO 8601 format with UTC as timezone, as this is the Kubernetes default afaik.

Describe alternatives you've considered

No response

Additional context

I use version 6.13.4

@manusa manusa added the bug label Nov 19, 2024
@manusa
Copy link
Member

manusa commented Nov 19, 2024

Looks like a bug.
If it's easy for you, can you try to see if this is still the case in the 7.0-SNAPSHOT. The bug is likely there still, but just in case.

@manusa manusa moved this to Planned in Eclipse JKube Nov 19, 2024
@Hoferl
Copy link
Author

Hoferl commented Nov 19, 2024

I would need to build it locally to have a 7.0-SNAPSHOT available, right?

@manusa
Copy link
Member

manusa commented Nov 19, 2024

The snapshots are published, you can enable them by adding this to your project pom.xml or global ~/.m2/settings.xml

      <repositories>
        <repository>
          <id>sonatype-snapshots</id>
          <url>https://oss.sonatype.org/content/repositories/snapshots</url>
          <releases><enabled>false</enabled></releases>
          <snapshots><enabled>true</enabled></snapshots>
        </repository>
      </repositories>

@Hoferl
Copy link
Author

Hoferl commented Nov 19, 2024

Hi, I was able to test it with the 7.0-SNAPSHOT version and like you assumed the behavior does not change, the bug is still there.

@manusa manusa self-assigned this Nov 25, 2024
@manusa manusa added this to the 7.0.0 milestone Nov 25, 2024 — with automated-tasks
@github-project-automation github-project-automation bot moved this from Review to Done in Eclipse JKube Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants