You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cayenne.apache.org by "Nikita Timofeev (Jira)" <ji...@apache.org> on 2023/05/19 07:29:00 UTC

[jira] [Updated] (CAY-2804) LocalTimeValueType potential loss of precision

     [ https://issues.apache.org/jira/browse/CAY-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nikita Timofeev updated CAY-2804:
---------------------------------
    Fix Version/s:     (was: 4.2)

> 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
>
>
> 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)