[
https://issues.apache.org/jira/browse/CAY-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2804.
--------------------------------
Resolution: Fixed
https://github.com/apache/cayenne/commit/25264972e9a4c32133c0d254fa6bbe133a165182
> LocalTimeValueType potential loss of precision
> ----------------------------------------------
>
> Key: CAY-2804
> URL: https://issues.apache.org/jira/browse/CAY-2804
> Project: Cayenne
> Issue Type: Bug
> Affects Versions: 4.2.RC2
> Reporter: Andrus Adamchik
> Assignee: Nikita Timofeev
> Priority: Minor
> Fix For: 5.0-M1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I just ran into a problem (outside Cayenne) when conversion between
> "java.sql.Time" and "java.time.LocalTime" in either direction results in the
> loss of precision when based on the standard API (Time.valueOf(LocalTime) and
> Time.toLocalTime()). Everything is rounded to whole seconds.
> I think our LocalTimeValueType is also affected by this problem.
> Below is how I addressed it in Agrest. The use of "ZoneId.systemDefault()" in
> that implementation is somewhat questionable, but seems compatible with
> Time.toLocalTime() / Time.valueOf(LocalTime).
> *
> https://github.com/agrestio/agrest/blob/master/agrest-engine/src/main/java/io/agrest/converter/jsonvalue/SqlTimeConverter.java
> *
> https://github.com/agrestio/agrest/blob/master/agrest-engine/src/main/java/io/agrest/converter/valuestring/SqlTimeConverter.java
> Interestingly, no other conversions (like Timestamp to LocalDateTime) are
> affected. Their JDK versions are working properly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
