[
https://issues.apache.org/jira/browse/ARROW-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926977#comment-15926977
]
Wes McKinney commented on ARROW-617:
------------------------------------
> Couldn't we just store nanoseconds in all cases? Are we concerned about the
> cost of conversion?
The trouble is that sometimes you are interacting with "someone else's memory".
So if you encounter a C array that represents time, it may be anywhere from
second to nanosecond resolution in practice. I've just run into this problem
with dates and added a {{date32}} type to the C++ library so that I can
interact with days-since-UNIX-epoch as {{int32_t}} with zero copy.
The most compatible solution that maximizes ability to do zero-copy reference
to memory is
- 64 bit type permitting any unit (second through nanosecond)
- 32 bit type permitting only seconds and milliseconds
In the format documents I think we should encourage only using 64 bits for
micro and nanoseconds, and 32 bits otherwise.
> Time type is not specified clearly
> ----------------------------------
>
> Key: ARROW-617
> URL: https://issues.apache.org/jira/browse/ARROW-617
> Project: Apache Arrow
> Issue Type: Bug
> Components: Format
> Reporter: Julien Le Dem
>
> 2 options:
> - Use 64 bits for microseconds and nanoseconds, 32 bits for other units
> - Use 64 bits for everything
> The latter is simpler to implement, the former saves space.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
