You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@arrow.apache.org by "Paul Taylor (Jira)" <ji...@apache.org> on 2022/06/02 02:37:00 UTC
[jira] [Commented] (ARROW-16543) [JS] Timestamp types are all the same
[ https://issues.apache.org/jira/browse/ARROW-16543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545241#comment-17545241 ]
Paul Taylor commented on ARROW-16543:
-------------------------------------
[~terusus] how did you construct the Timestamp Vectors? The semantic meaning of the type is "<duration> since the epoch," so it's valid for the different duration dtypes to have the same underlying representation.
> [JS] Timestamp types are all the same
> -------------------------------------
>
> Key: ARROW-16543
> URL: https://issues.apache.org/jira/browse/ARROW-16543
> Project: Apache Arrow
> Issue Type: Bug
> Components: JavaScript
> Reporter: Teodor Kostov
> Priority: Major
>
> Current timestamp types are all the same. They have the same representation. And also the same precision.
> For example, {{TimestampSecond}} and {{TimestampMillisecond}} return the values as {{1652118180000}}. Instead, I would expect the {{TimestampSecond}} to drop the 3 zeros when returning a value, e.g. {{1652118180}}. Also, the representation underneath is still an {{int32}} array. Even though for {{TimestampSecond}} every second value is {{0}}, the array still has double the amount of integers.
> I also got an error when trying to read a {{Date}} as {{TimestampNanosecond}} - {{TypeError: can't convert 1652118180000 to BigInt}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)