[BUG] Java OffsetDateTime default values generated at Zone it is generated / Code depends on locale of PC

For java code generation / pojo:

If I generate a DateTime with default value from:

      startdate:
        type: string
        format: date-time
        default: "1970-01-01T00:00:00Z"

The generated code is:

public static final String JSON_PROPERTY_STARTDATE = "startdate";
private OffsetDateTime startdate = OffsetDateTime.parse("1970-01-01T01:00+01:00[Europe/Berlin]", java.time.format.DateTimeFormatter.ISO_ZONED_DATE_TIME.withZone(java.time.ZoneId.systemDefault()));

The generated code is dependent on the area it is generated, so my colleagues in Asia will get a different generated code!

The issue is at:

https://github.com/OpenAPITools/openapi-generator/blob/a8efb8eea8a8136311db2fa4dfea6df39d1c3d4a/modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/AbstractJavaCodegen.java#L1243C86-L1244C21

Where the code is first printed as: .atZoneSameInstant(ZoneId.systemDefault()) and than parsed with: .withZone(java.time.ZoneId.systemDefault())

                    return String.format(Locale.ROOT, "OffsetDateTime.parse(\"%s\", %s)",
                            ((java.time.OffsetDateTime) schema.getDefault()).atZoneSameInstant(ZoneId.systemDefault()),
                            "java.time.format.DateTimeFormatter.ISO_ZONED_DATE_TIME.withZone(java.time.ZoneId.systemDefault())");

Besides generating code dependent on the PC/locale it might also cause issues, when the date is in future and a change in Summer/Winter Time happens and Java will use the Zone for checking the offset (which is currently not the case).

Why was the .atZoneSameInstant(ZoneId.systemDefault()) and .withZone(java.time.ZoneId.systemDefault()) introduced? We have a OffsetDateTime which is a correct representation parsed from the default. Why not just use as is?

I would suggest to not use any Zone Information in the OffsetDateTime. Just print the parsed OffsetDateTime schema.getDefault().toString;

Same is also true for LocalDate:

                    Date date = (Date) schema.getDefault();
                    LocalDate localDate = date.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();
                    return String.format(Locale.ROOT, "LocalDate.parse(\"%s\")", localDate.toString());

Might actually change the date, depending on the locale the code is generated in:

    final Date date = new Date(1708982798097l);

    final LocalDate localDate = date.toInstant().atZone(ZoneId.of("Asia/Tokyo")).toLocalDate();
    final LocalDate localDate2 = date.toInstant().atZone(ZoneId.of("Europe/Berlin")).toLocalDate();
    System.out.println(String.format(Locale.ROOT, "LocalDate.parse(\"%s\")", localDate.toString()));
    System.out.println(String.format(Locale.ROOT, "LocalDate.parse(\"%s\")", localDate2.toString()));

Will return:

LocalDate.parse("2024-02-27")
LocalDate.parse("2024-02-26")

Start in modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/AbstractJavaCodegen.java around the reported default-value generation code. Trace the OffsetDateTime and LocalDate paths and compare generated output under different system time zones. Done means generated defaults preserve the schema value and no longer depend on the generator machine's locale or zone.