It looks like between
- ARROW-316 https://issues.apache.org/jira/browse/ARROW-316
- ARROW-617 https://issues.apache.org/jira/browse/ARROW-617
- ARROW-637 https://issues.apache.org/jira/browse/ARROW-637
We should be in pretty good shape with the date and time type
specification. Once we reach cons
@JulienLD or @Jacques could you add your perspective on the JIRA from
the Java side? Would be good to reach a consensus on this so we can
make appropriate changes. We will want to push towards integration
tests for the various date and time types in the 0.3 release
If JulienH could also offer some
The first option makes it easier for compatibility with existing code
I opened a JIRA to discuss:
https://issues.apache.org/jira/browse/ARROW-617
On Fri, Mar 10, 2017 at 4:42 PM, Wes McKinney wrote:
> There's two routes, I guess:
>
> - Use 64 bits for microseconds and nanoseconds, 32 bits for ot
There's two routes, I guess:
- 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. I am not
sure which is the better solution. Another situation where this will
occur is with decimals, where
It sounds like we need to specify a different bit width depending on the
unit?
millisecond time fits in 32 bits but neither do micros nor nanos.
the java TimeVector uses 32 bit for now (and supports millis only):
https://github.com/apache/arrow/blob/6b3ae2aecc8cd31425035a021fa04b9ed3385a8d/java/vec
Sorry to be a little slow to respond on this.
Since we support nanosecond time unit, we need to use 64 bits. So it
sounds like the bug is on the Java side
On Fri, Mar 10, 2017 at 4:47 PM, Bryan Cutler wrote:
> Thanks for the info Julien. I'll open a JIRA for fixing the type layout
> for TIME, a
Thanks for the info Julien. I'll open a JIRA for fixing the type layout
for TIME, and I'll give the documentation a shot.
Regards,
Bryan
On Thu, Mar 9, 2017 at 9:01 PM, Julien Le Dem wrote:
> Hi Bryan,
> In the JSON representation we should use the integer representation of the
> Timestamp. We
Hi Bryan,
In the JSON representation we should use the integer representation of the
Timestamp. We should not depend on joda for this.
DATE is on 8 bytes => 64bits:
https://github.com/apache/arrow/blob/6b3ae2aecc8cd31425035a021fa04b9ed3385a8d/format/Message.fbs#L79
https://github.com/apache/arrow/
I guess it would make sense to just store the time of day value in
milliseconds to go along with the DATE type that contains days since epoch,
which would fit into a 4 byte value. Only I see conflicting code in
TypeLayout.java that defines the schema as 64 bit width
public TypeLayout visit(Time t
Hello All,
I've started work on ARROW-582 to add Date/Time support for Java JSON files
and would just like to clear up a few things. I believe the Java Time type
is supposed to represent milliseconds since epoch, it is stored as a
FixedValueVector with a width of 4 bytes (equivalent to Java 'int'
10 matches
Mail list logo
