Open jeff303 opened 3 years ago
Consider the following REPL session, in which version 0.3.2 of the library is being used (as per the deps.edn guide here).
0.3.2
(import java.time.temporal.ChronoField) (import java.time.temporal.Temporal) (def my-local-time (t/local-time 1 12 13 456000000)) (t/sql-time my-local-time) #inst "1970-01-01T07:12:13.000-00:00"
Notice that the millisecond portion (456) is lost. In principle, though, it is possible to build the java.sql.Time instance to have that information:
456
java.sql.Time
(let [millis-of-day (.get my-local-time ChronoField/MILLI_OF_DAY)] (java.sql.Time. millis-of-day)) #inst "1970-01-01T01:12:13.456-00:00"
The same problem occurs in reverse as well:
(def my-sql-time (let [millis-of-day (.get my-local-time ChronoField/MILLI_OF_DAY)] (java.sql.Time. millis-of-day))) (t/local-time my-sql-time) #object[java.time.LocalTime 0xda22aa "19:12:13"]
Again, it's possible to preserve that information (probably more elegantly than this):
(import java.time.LocalTime) (LocalTime/ofNanoOfDay (* 1000000 (.getTime my-sql-time))) #object[java.time.LocalTime 0x10d98940 "01:12:13.456"]
This happens due to the implementation of java.sql.Time/valueOf:
java.sql.Time/valueOf
https://github.com/openjdk/jdk/blob/eeb345a286115213f8a75dfe54cdcc39dfca597a/src/java.sql/share/classes/java/sql/Time.java#L252-L255
Consider the following REPL session, in which version
0.3.2
of the library is being used (as per the deps.edn guide here).Notice that the millisecond portion (
456
) is lost. In principle, though, it is possible to build thejava.sql.Time
instance to have that information:The same problem occurs in reverse as well:
Again, it's possible to preserve that information (probably more elegantly than this):