Implementing a workaround for an invalid format in the defaultValue.

[d-hrs]

get fields api returns defaultValue in the format of yyyy-MM-dd'T'HH:mm. e.g. 2023-12-08T12:34.
This value is lack of compatibility with the ISO-8601 format, so DateTimeParseException occurs like following.

java.time.format.DateTimeParseException: Text '2019-03-27T10:15' could not be parsed: Unable to obtain ZonedDateTime from TemporalAccessor: {},ISO resolved to 2019-03-27T10:15 of type java.time.format.Parsed

This is a workaround until the API returns the expected format.

[d-hrs]

@tomohiro-okuyama could you review it?

[tomohiro-okuyama]

@d-hrs
Thank you for your report.
This is a bug in the Java client, but it looks difficult to get a consistent fix in a short time without breaking backward compatiiblity.

The default value for a DATETIME field is used as the local time, and it does not have the timezone information by design.
The Java client should use LocalDateTime instead of ZoendDateTime for this data.
We'd like to consider fixing this issue in the next major version update.

[d-hrs]

@tomohiro-okuyama
Thank you for your comment.

The default value for a DATETIME field is used as the local time, and it does not have the timezone information by design.
The Java client should use LocalDateTime instead of ZoendDateTime for this data.

I see, it's not a bug in the API. I will close this pull request.

We'd like to consider fixing this issue in the next major version update.

When do you plan to fix?

[tomohiro-okuyama]

@d-hrs
Unfortunately, we don’t have any confirmed information to share regarding the update schedule at this time.

[d-hrs]

@tomohiro-okuyama
Sorry for the late reply.

Thanks for your reply. I'm waiting for the new release.