You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ChunkInputStreamGenerator currently picks a deserialization strategy based on the destination java class type. If we also pass in an ArrowType then we could support encoding/decoding java types to multiple arrow formats.
For example we support Date if represented as 64-bit number of days since the epoch * ms_in_a_day, but we do not support Date if represented as 32-bit number of days since the epoch.
Similarly, TimeUnit can be represented in seconds, milliseconds, microseconds and nanoseconds. Currently we only support nanoseconds serialization/deserialization. We could do better with some refactoring. This is referring to LocalTime.
ZonedDateTime should keep time zone as specified in the schema instead of picking the JVM default.
The text was updated successfully, but these errors were encountered:
ChunkInputStreamGenerator currently picks a deserialization strategy based on the destination java class type. If we also pass in an
ArrowType
then we could support encoding/decoding java types to multiple arrow formats.For example we support Date if represented as 64-bit number of days since the epoch * ms_in_a_day, but we do not support Date if represented as 32-bit number of days since the epoch.
Similarly, TimeUnit can be represented in seconds, milliseconds, microseconds and nanoseconds. Currently we only support nanoseconds serialization/deserialization. We could do better with some refactoring. This is referring to
LocalTime
.ZonedDateTime should keep time zone as specified in the schema instead of picking the JVM default.
The text was updated successfully, but these errors were encountered: