Closed d-hrs closed 9 months ago
@tomohiro-okuyama could you review it?
@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.
@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?
@d-hrs Unfortunately, we don’t have any confirmed information to share regarding the update schedule at this time.
@tomohiro-okuyama Sorry for the late reply.
Thanks for your reply. I'm waiting for the new release.
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.This is a workaround until the API returns the expected format.