fix: (java-generator) Use timezone format compatible with Kubernetes

[matteriben]

Description

fix: (java-generator) Use timezone format compatible with Kubernetes
Fixes #7116

Example error message:

Invalid value: "2025-05-30T23:04:44Zulu": startTime in body must be of type date-time

See also:
https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change
• Chore (non-breaking change which doesn't affect codebase;
  test, version modification, documentation, etc.)

Checklist

• Code contributed by me aligns with current project license: Apache 2.0
• I Added CHANGELOG entry regarding this change
• I have implemented unit tests to cover my changes
• I have added/updated the javadocs and other documentation accordingly
• No new bugs, code smells, etc. in SonarCloud report
• I tested my code in Kubernetes
• I tested my code in OpenShift

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[manusa]

LGTM, thx!

[andreaTP]

Sorry for being late at the party here, date time has been especially challenging when it comes to date-time, the original fix was done in #5384
I distinctly remember choosing different formats for writing(stricter) than for reading, and allowing more use cases reported on SO.

In this case, I'd be a bit on the fence accepting a PR without an exhaustive set of examples to cover the change.
cc. @manusa

[andreaTP]

@matteriben here you are effectively restricting the date-time formats accepted by the deserializer, any specific reason for doing it?

[matteriben]

@andreaTP I'm sorry for the delayed response. Yes, that is right. This change does restrict date-time formats accepted by the deserializer. However, as far as I understand the formats no longer accepted (for example, 'Europe/Paris') are also not supported by the kubernetes api server.

https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html

  Symbol  Meaning                     Presentation      Examples
  ------  -------                     ------------      -------
   V       time-zone ID                zone-id           America/Los_Angeles; Z; -08:30
   X       zone-offset 'Z' for zero    offset-X          Z; -08; -0830; -08:30; -083015; -08:30:15;

ZoneId: This outputs the time-zone ID, such as 'Europe/Paris'. If the count of letters is two, then the time-zone ID is output. Any other count of letters throws IllegalArgumentException.

Offset X and x: This formats the offset based on the number of pattern letters. One letter outputs just the hour, such as '+01', unless the minute is non-zero in which case the minute is also output, such as '+0130'. Two letters outputs the hour and minute, without a colon, such as '+0130'. Three letters outputs the hour and minute, with a colon, such as '+01:30'. Four letters outputs the hour and minute and optional second, without a colon, such as '+013015'. Five letters outputs the hour and minute and optional second, with a colon, such as '+01:30:15'. Six or more letters throws IllegalArgumentException. Pattern letter 'X' (upper case) will output 'Z' when the offset to be output would be zero, whereas pattern letter 'x' (lower case) will output '+00', '+0000', or '+00:00'.

[andreaTP]

the VV format should be "stricter" (emit a more stable output) than XXX across different Java/JDK versions IIRC.

[matteriben]

@andreaTP I'm sorry for the delayed response. As far as I understand 'VV' will output a string like 'Europe/Paris' or 'Zulu' (which kubernetes api server does not accept as date-time). As for 'XXX' as far as I understand it should output "the hour and minute, with a colon, such as '+01:30'.", or "'Z' when the offset to be output would be zero".

Indeed, this is what I see with jshell (21.0.6):

jshell> java.time.format.DateTimeFormatter.ofPattern("XXX").format(java.time.ZonedDateTime.now())
$1 ==> "-05:00"

jshell> java.time.format.DateTimeFormatter.ofPattern("XXX").format(java.time.ZonedDateTime.now(java.time.ZoneOffset.UTC))
$2 ==> "Z"

As for the behavior across different Java/JDK versions, I found JDK-8066806. This seems to be a parsing bug, and I'm not sure if this bug was what you were referring to? I don't really understand what was fixed ('-8:00' is not valid, '-08:00' is valid). I think this bug could potentially cause inconsistent behavior with older builds of Java 8. It's not clear to me if parsing with "[XXX][VV]" instead of "XXX" would be an effective workaround for this bug.

[matteriben]

Sorry for being late at the party here, date time has been especially challenging when it comes to date-time, the original fix was done in #5384 I distinctly remember choosing different formats for writing(stricter) than for reading, and allowing more use cases reported on SO.

In this case, I'd be a bit on the fence accepting a PR without an exhaustive set of examples to cover the change. cc. @manusa

@andreaTP I'm also sorry for the delayed response here, I agree with you that this could benefit from more exhaustive test coverage. In particular the output of the serializer should be considered valid by the kubernetes api server and the deserializer should be able to handle anything that the kubernetes api server considers valid.